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(57) Abstract: A method and system for providing user interfaces in a first network including first devices interconnected via a com- 
munication medium and at least one interface device connecting said first network to at least a second network having interconnected 
second devices providing services, the user interfaces for controlling the devices that are currently connected to the first network 
and devices that are currently connected to the second network. In each of one or more first devices in the first network a process 
includes: (a) obtaining information from one or more of said first devices currently connected to the first network, said information 
including device information; and (b) generating a user interface description including: (I) at least one reference associated with the 
device information of each of said one or more first devices, (2) at least a redirection identification code (RIC) corresponding to that 
first device, and (3) at least one reference associated with the services provided by the second network. The second network includes 
at least a first portal and at least a destination service provider for providing services, and the method further comprises the steps of: 
at least a first device requesting service from the second network by sending a request including an RIC to the first portal using a 
reference in the user interface description, the first portal determining a destination service provider based on the received RIC, and 
the first portal redirecting the request to the destination service provider. The destination service provider in the second network can 
be internal or external to the first portal. 
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DEVICE COMMUNICATION AND CONTROL IN A HOME 
NETWORK CONNECTED TO AN EXTERNAL NETWORK WITH 
REGIONAL SUPPORT 



Technical Field 

The present invention relates to the field of networks, and more 
particularly, to home networks having multi-media devices connected thereto. 

10 <Notice of Inclusion of Copyrighted Material 

A portion of the disclosure of this patent document contains material 
which is subject to copyright protection. The copyright owner has no objection 
to the facsimile reproduction by anyone of the patent disclosure, as it appears 
in the Patent and Trademark Office patent files or records, but otherwise 

15 reserves all copyright rights whatsoever. 

<Cross-References to Related Applications> 

Applicants claim the benefit of U.S. Provisional Application No. 
60/166,602 entitled "Regional Service Support for Home Network Top-Level 
20 Home Page and External Device Manufacturer's Portal Services," filed on 
November 19, 1999 which application is incorporated herein by reference. 



Background Art 

A network generally includes a communication link and various devices 
25 with communication capability connected to the communication link. The 
devices include computers, peripheral devices, routers, storage devices, and 
appliances with processors and communication interfaces. An example of a 
network is a home network for a household in which various devices are 
interconnected. A usual household can contain several devices including. 
30 personal computers and home devices that are typically found in the home. As 
such the term "device" typically includes logical devices or other units having 
functionality and an ability to exchange data, and can include not only all home 
devices but also general purpose computers. Home devices include such 
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electronic devices as security systems, theater equipment. TVS, VCRs, stereo 
equipment, and direct broadcast satellite services or (DBSS), also known as 
digital satellite services (DSS), sprinkler systems, lighting systems, micro 
waves, dish washer, ovens/stoves, washers/dryers, and a processing system 
5 in an automobile. 

In general, home devices are used to perform tasks that enhance a 
homeowner's life style and standard of living. For example, a dishwasher 
performs the task of washing dirty dishes and relieves the homeowner of 
having to wash the dishes by hand. A VCR can record a TV program to allow 
a homeowner to watch a particular program at a later time. Security systems 
protect the homeowner's valuables and can reduce the homeowner's fear of 
unwanted entry. 



10 



15 



Home devices, such as home theater equipment, are often controlled 
using a s.ngle common control unit, namely a remote control device This 
single common control unit allows a homeowner to control and command 
several different home devices using a single interface. Thus may 
manufacturers have developed control units for controlling and commanding 
20 their home devices from a single interface. 

One drawback associated with using the remote control unit to 
command and control home devices is that it provides static and command 
logic for controlling and commanding each home device. Therefore, a particular 
remote control unit can only control and command those home devices for 
wh,ch it includes the necessary control and command logic. For example if 
a remote control unit comprises logic for controlling a television (TV), a video 
cassette recorder (VCR), and a digital video device (DVD), but not a compact 
d.sk (CD) unit, the remote control unit can not be used to command and control 
the CD unit. In addition, as new home devices are developed, the remote 
control unit will not be able to control and command the new home devices that 
require control and command logic that was not known at the time the remote 



25 
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control unit was developed. 

Further, typically a remote control unit can only be used to command 
and control those home devices that are within the signal range of the remote 
5 control unit. Therefore, a user cannot use the remote control unit from a 
single location in the house to control and command home devices that are 
interconnected, but located in separate areas of the home. For example, a 
VCR that is located upstairs in a bedroom may be connected to a TV that is 
downstairs in the family room. If a user wishes to play a tape contained in the 

10 VCR located upstairs in the bedroom, on the TV located downstairs in the 
family room, the user cannot control and command both the TV and the VCR 
from a single location. 

Another drawback associated with using remote control units is that 
known remote control units cannot control a plurality of diverse devices, and 

15 more particularly, cannot control a plurality of devices having different 
capabilities to communicate with each other in order to accomplish tasks or 
provide a service. Further, conventional network systems do not provide a 
mechanism for software applications in different network devices to 
automatically communicate with one another in order to accomplish tasks 

20 without direct user command. 

To alleviate the above problems, some network models provide a 
central/singular user interface (Ul) in one device including static device 
information for networked devices for user control of network devices. 

25 However, in such networks a change to device information (e.g., ICON) in a 
device requires a change to, and rebuilding of, the top level page. Further, 
if the device displaying the central user interface becomes unavailable, user 
control of the network is curtailed. Another problem with the central/singular 
page is that every Ul device must display the same page, and a scope is not 

30 provided for each manufacturer to generate its own Ul look and feel nor alter 
the technology used in the Ul device. The content of an icon/information 
representing a device cannot be changed, and a Ul device cannot display a 
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more prominent look to a device icon such as the icon for the Ul device itself. 
Nor can a Ul builder tool obtain e-business icons from an external Web Portal. 
Such a model cannot be standardized for industry use because a 
central/single Ul device controls the Ul. 

5 

Further, existing networks only allow communication and control of 
devices connected to a network (e.g., 1394) using said central user interface, 
without the ability to provide user interface and control of devices and services 
connected to another different network (e.g., Internet). 

10 

There is, therefore, a need for a method and a system which provides 
dynamic control and command devices in a home network. There is also a 
need for such a method and system to provide the ability for accessing devices 
connected to a first network and accessing devices and services connected 

15 to a second different network, and to independently generate different user 
interface representations of the devices connected to the first and of devices 
and services connected to the second network for user control and 
communication. There is also a need for such a method and system to provide 
regional service and support for devices located in different geographical 

20 regions. 

Disclosure of the Invention 

The present invention satisfies these needs. In one embodiment, the 
present invention provides a method and system for providing user interfaces 

25 in a first network including first devices interconnected via a communication 
medium and at least one interface device connecting said first network to at 
least a second network having interconnected second devices providing 
services, the user interfaces for controlling the devices that are currently 
connected to the first network and devices that are currently connected to the 

30 second network. In one version, the method comprises the steps of, in each 
of one or more first devices in the first network: (a) obtaining information 
from one or more of said first devices currently connected to the first network, 
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said information including device information; and (b) generating a user 
interface description including: (1)at least one reference associated with the 
device information of each of said one or more first devices, (2) at least a 
redirection identification code (RIC) corresponding to that first device, and (3) 
5 at least one reference associated with the services provided by the second 
network. 

The second network includes at least a first portal and at least a 
destination service provider for providing services, and the method further 

10 comprises the steps of: at least a first device requesting service from the 
second network by sending a request including an RIC to the first portal using 
a reference in the user interface description, the first portal determining a 
destination service provider based on the received RIC, and the first portal 
redirecting the request to the destination service provider. The destination 

15 service provider in the second network can be internal or external to the first 
portal. 

A reference associated with services provided by the second network 
comprises at least one hyper-link to said first portal, wherein the first portal 

20 includes service information comprising at least redirection information based 
on RICs to services provided by other service providers in the second network. 
The first portal further includes a list of RICs and corresponding destination 
service provider portal addresses, such that the steps of determining a 
destination service provider further includes the steps of looking up in said list 

25 a destination service provider portal address corresponding to a received RIC, 
and redirecting the request to said destination service provider portal address. 
Each destination service provider address can comprise a URL. The RIC an 
be obtained from a user or automatically . For at least one user device, the 
corresponding RIC comprises an identifier representing the geographical 

30 region of the first device. 

A user interface is displayed based on each user interface description 
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on a device connected to the first network capable of displaying a user 
interface, for user control of said first devices and communication with said 
second devices. Displaying each user interface is based on using each 
reference in the corresponding user interface description to access the 
5 associated information in each first device, and associated service information 
in each second device; generating the user interface including information 
corresponding to each device using the accessed information in each device; 
and displaying the user interface on said device capable of displaying a user 
interface. 

10 

Brief Description of the Drawings 

These and other features, aspects and advantages of the present 
invention will become better understood with regard to the following description, 
appended claims and accompanying drawings where; 
'5 FIG. 1 shows an example block diagram of the architecture of an 

embodiment of a network according to the present invention; 

FIG. 2 shows an example block diagram of the architecture another 
embodiment of a network according to the present invention; 

FIG. 3 illustrates an example of a layered interface model that can be 
20 used for communicating between home devices in accordance with the present 
invention; 

FIG. 4a shows an example architecture diagram of a DVCR server 
device replaying video to a DTV client device capable of displaying a user 
interface, in a network according to the present invention; 
25 FIG. 4b shows another example architecture diagram of a server device 

communicating with a client device capable of displaying a user interface, in 
a network according to the present invention; 

FIGS. 5-6 illustrate example top-level GUIs representing the functions 
of networked devices to a user; 
30 FIG. 7 shows an example block diagram architecture of a home network 

constructed in accordance with another embodiment of the present invention; 

FIG. 8 shows an example process according to the present invention 
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for communication between a 1394 network and a non-1394 network for IP 
address configuration; 

FIGS. 9a-c show example functional block diagrams of connections to 
data and control bits of an embodiment of a discovery system architecture in 
5 a network according to another aspect of the present invention; 

FIG. 10 shows an example flow diagram for discovery and configuration 
agents in the home network in connection with the functional block diagrams 
in FIGS. 9a-c; 

FIG. 1 1 shows an example flow diagram for user interface description 
10 generator agent in the home network in connection with the functional block 
diagrams in FIGS. 9a-c; 

FIG. 12 shows a pictorial outline of a top level network user interface 
description including links to external services, showing actual icon and name 
HTML file references and addresses, according to another aspect of the 
15 present invention; 

FIG. 13 shows example top-level GUI representing the functions of 
devices in a home network and services provided by an external network, 
based on the user interface description of FIG. 12; 

FIG. 14 shows another example process according to another aspect 
20 of the present invention for communication between a 1 394 network and a non- 
1394 network for IP address configuration; 

FIG. 15 shows an example flow diagram for user interface description 
generator agent in the home network for generating a top level network user 
interface description including links to external services, according to another 
25 aspect of the present invention ; 

FIG. 16 shows a pictorial outline of a top level network user interface 
description including links to external services and regional identification codes 
(RIC) using Zip codes, showing actual icon and name HTML file references 
and addresses, according to another aspect of the present invention; 
30 FIG. 1 7 shows an example method of user configuration wherein a user 

can input general RIC information such as Zip code or area code for regional 
support; 
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FIG. 18 shows an example method of automatic configuration for 
obtaining IP addresses as RICs via service providers' system; 

FIG. 19 shows an example flowchart of steps of an embodiment of 
redirection according to the present invention in conjunction with FIG. 17; 
5 FIG. 20 shows an example flowchart of steps of another embodiment 

of redirection according to the present invention in conjunction with FIG. 18; 
and 

FIG. 21 shows an example block diagram of architecture of a network 
system including several home networks, and several external networks, 
10 interconnected via a communication network such as the Internet, wherein 
redirection based on RIC is implemented according to an aspect of the present 
invention. 

Appendices 1-4, illustrative examples for: (1) Top-Level Page 
1 5 description 250 (Appendix 1 ); (2) Background.htm (Appendix 2); (3) lcon.htm 
(Appendix 4); and (4) Name.htm (Appendix4); 

Appendices 5-12, illustrative examples for the following htm files for 
generating the top level home network user interface description and GUI in 
FIGS. 12-13 including external links, wherein: 
20 Appendix 5 - illustrates Top-Level Page Example TLNUID (index.htm) 

Appendix 6 - example background.htm; 

Appendix 7 - illustrates example icon.htm; 

Appendix 8 - illustrates example name.htm; 

Appendix 9 - illustrates example logoiconl .htm; 
25 Appendix 1 0 - illustrates example logonamel .htm; 

Appendix 1 1 - illustrates example logoicon2.htm; 

Appendix 12 - illustrates example logoname2.htm; 

Appendix 13 illustrates a Perl Example Program for Trace Route for 
regional service; 

30 Appendix 14 illustrates example of a redirection program; 

Appendices 15, 6, 7, 8, 16, 17, 18, and 19, illustrative examples for htm 
files for generating the top level home network user interface description and 
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GUI in FIGS. 13 and 16 including external links with regional support, wherein: 
Appendix 15 - illustrates Top-Level Page Example TLNUID (index.htm) 
Appendix 16 - illustrates example logoicon1.htm; 
Appendix 17 - illustrates example logoname1.htm; 
5 Appendix 1 8 - illustrates example logoicon2.htm; and 

Appendix 19 - illustrates example logoname2.htm. 

To facilitate understanding, identical reference numerals have been 
used, where possible, to designate identical elements that are common 
10 throughout the figures. 

Best mode for carrying out the Invention 

<Network Overview> 
15 Referring to FIG. 1, in an embodiment of the present invention, a 

network 10 comprises multiple devices 11 including at least one client device 
12 and at least one server device 14 interconnected via a communication link 
16. The communication link 16 can include a 1394 serial bus providing a 
physical layer (medium) for sending and receiving data between the various 
20 connected home devices. The 1394 serial bus supports both time-multiplexed 
audio/video (AA/) streams and standard IP (Internet Protocol) communications 
(e.g., IETF RFC 2734). In certain embodiments, a home network uses an IP 
network layer as the communication layer for the home network. However, 
other communication protocols could be used to provide communication for the 
25 home network. For example, the invention may be implemented using Function 
Control Protocol (FCP) as defined by IEC 61883, or any other appropriate 
protocol. Thus, a network may generally include two or more devices 
interconnected by a physical layer exchange or transfer of data in accordance 
with a predefined communication protocol. 

30 

Each client device 12 may communicate with one or more server 
devices 14 in the network 10. Further, each server device 14 may 
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communicate with one or more other server devices 14, and one or more client 
devices 12, in the network 10. Each client device 12 can include a user 
communication interface including input devices such as a mouse and 
keyboard for receiving user input, and a display for providing a control user 
5 interface for a user to interact with the networked devices. The user interface 
can include a graphical user interface (GUI) 18 for providing information to the 
user. Each server device 14 includes hardware as a resource in the network 
for providing services to the user, and can further include a server or service 
control program 20 for controlling the server hardware. 

10 

Each server device 14 provides a service for the user, except control 
user interface, and each client device 12 provides a service including control 
user interface for user interaction with the network 10. As such, only client 
devices 12 interact directly with users, and server devices 14 interact only with. 
15 client devices 12 and other server devices 14. Example services can include 
MPEG sourcing/sinking and display services. 

In an exemplary embodiment of the present invention, a browser based 
network (e.g., a home network) uses Internet technology to control and 

20 command devices including client devices and server devices that are 
connected to a network. Each device includes device information such as 
interface data (e.g. HTML, XML, JAVA, JAVASCRIPT.GIF, JPEG, graphics 
files, or any other format useful for the intended purpose) that provides an 
interface for commanding and controlling of the device over the network. In 

25 certain embodiments, each device includes device information such as one or 
more Hypertext markup Language (HTML) pages that provide for the 
commanding and controlling of that device. Using the browser technology, 
the network employs Internet standards to render the HTML pages in order to 
provide users with a plurality of graphical user interface (GUIs) for commanding 

30 and controlling each device. In one example, the network is configured as an 
intranet. 
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In one embodiment, a client device comprises a device providing control 
interface service to a human operator, including a graphical display hardware 
for down communication and a mouse or other point-and-click device for up 
(or return) communication. A server device comprises a module supplying a 
5 service, which can be any service other than a control interface provided by 
a client device. As such, the server/client device relationship is a control 
relationship, wherein the server device provides a service but a client device 
can use the data, as a DTV displays video data, but need not manipulate or 
alter the data. It is thus consistent with this definition to observe that, 
10 frequently, a server may be a source of information and a client (a browser, for 
example) may be a consumer of information. 

Examples of specific functions which can be implemented by server 
devices include: return of information (data); performance of a function (e.g., 

15 mechanical function) and return of status; return of a data steam and status; 
reception of a data stream and return of status; or saving of a state for 
subsequent action. Examples of server devices include MPEG source, sink 
and display servers. While a server device typically includes a custom, built-in, 
control program to implement control of its own hardware, a client functions to 

20 interface with the server device. However, server device as used herein does 
not imply that a web server and a protocol stack must be used. 

FIG. 2 shows a block diagram of an embodiment of a network 100 
according to an aspect of the present invention. A 1394 serial bus 114. 

25 described above, electronically connects multiple devices 1 1 including server 
devices 14 (e.g., DVD 108, DVCR 110), client devices 12 (e.g., DTV 102, 103), 
Bridge 1 16, DVCR120, PC 105, cable/modem access 107. and DBS access 
1 09, on the network 1 00. FIG. 3 illustrates an example of a layered interface 
model that can be used for communicating between the devices 11 in 

30 accordance with the present invention. In this example, a device (server) 150 
. communicates with a client device 166 using one or more of the network 
communication layers 1 52-1 64. In one example, an application in the device 
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150 communicates with an application in the device 166 via the network layer 
160. The details of lower layers 162 and 164 are not seen by the applications, 
whereby use of e.g. either 1394 or Ethernet does not make a difference to said 
applications in the devices 1 50, 166. Further not all the upper layers of the 
7-layer model are used all the time (e.g., in the Web model (TCP/IP model) 
session layer 156 and presentation layer 154 are not used). As such, in one 
version, by employing the Internet Protocol standard for the network layer 160, 
the devices can communicate with each other without having to know specific 
details about the other communication layers (i.e. application 152, presentation 
154, session 156, transport 158, data link 162 and physical 164). Thus, by 
employing the Internet Protocol standard for the network layer 160, the network 
can use a combination of different communication layers in communicating 
between different devices. 



A single physical package can include several devices which are 
logically networked via a network layer for example as shown in FIG. 3 not 
necessarily via a physical network (e.g., such devices can include a VCR and 
a TV in a single housing). Where a logical device accesses a GUI to enable 
a user to control a device, the device and the logical device can be included 
in the same physical package. In such an embodiment, the physical device 
fetches a GUI from itself. However, in other embodiments the network 
interconnects separate physical devices, wherein for example, a first device 
fetches a GUI from a second device, to permit user interaction with the GUI to 
control the second device. 

In a presently preferred embodiment, a 1394 serial bus is used as the 
physical layer 164 for the data communications on the network 100. Because 
of its enhanced bandwidth capabilities (e.g., enhanced and guaranteed 
bandwidth and isochronous stream capability), the 1394 serial bus can provide 
a single medium for all data communications on the network 100 (i.e. 
audio/video streams and command/control). 
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Further, the 1394 serial bus provides automatic configuration reset such 
that when a device is plugged in/removed all the 1394 interfaces reset, the 
1394 bus reconfigures and every device knows the presence of every other 
device (including a newly added one or without the one just removed). Also, 
5 the 1 394 interface supports a data space for configuration information that is 
addressable from any device allowing other devices to write/read information 
and make modifications e.g. to permit the operation of the network layer 
protocol. However, it is possible to achieve these results with different software 
and standards. As such, the network 100 is not restricted to using a 1394 
10 serial bus, and, in alternative embodiments of the present invention, other bus 
types, such a Ethernet, ATM, wireless, etc., can be used as the physical layer 
if they meet the particular throughput requirements of an individual network 
(e.g., a home network) . Further, a modified version of e.g. wireless-Ethernet 
can include the essential features of 1 394. 

15 

As depicted in FIG. 2, the network 100 includes several devices 
connected to the 1394 serial bus 1 14. In this example, the devices include a 
DBSS 104 for receiving transmission signal from a satellite 122 for subsequent 
display. Associated with the DBSS is a network interface unit ("NIU") which, 
20 among other things, provides an interface between the. DBSS satellite 
transmission and the 1 394 serial bus 114. 

A digital video device (DVD) 108 is also connected to the exemplary 
network 1 00. The DVD 1 08 can be used to display digitally encoded videos 

25 on a television. Also connected to the exemplary network 1 00 is a digital video 
cassette recorder (DVCR) 110, i.e., a digital TV 102. In this example, the DTV 
102 provides a human interface for the network 100 by employing browser 
technology to allow users to control and command for devices over the home 
network 100. A second DTV 103 provides another human interface for the 

30 network 100 by employing browser technology to allow users to control and 
command for devices over the home network 100. The DTVs 102 and 103 
can provide human interfaces for the network 100 as each DTV comprises a 
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screen for displaying HTML pages. However other devices having display 
capability can be used to provide human interfaces. Thus, in certain 
embodiments of the invention, a device such as the personal computer 105 
(PC) is used to provide a human interface for a respective home network, as 
5 a PC 105 typically embodies a screen display unit. 

The 1394 serial bus 114 is depicted as using the HTTP/IP interface 
protocol, and preferably HTTP/TCP/IP, wherein IP provides packet format (a 
one-way write only model), TCP provides an error free version of IP (e.g., 

10 ensures packets arrive and in correct order), and HTTP provides 2-wa 
connection (packet to server will expect a response -a 'read' model). Certain 
devices can require other protocol interface types (e.g., UPD/IP, 
FTP/IP.TELNET/IP, SNMP/IP, DNS/IP, SMTP/IP). In certain embodiments 
of the invention, a proxy 116 can be used to interface two networks using 

15 dissimilar interface protocols on their respective mediums which, when 
connected, comprise the network 1 00. The proxy 1 1 6 (e.g. Web proxy) can 
include Home Automation type protocols such as the HTML/HTTPfTCP/IP 
proxy for X10. Lonworks, CEBus (on their respective physical technologies), 
or non-IP protocols on 1394 (e.g., AVC/FCP/1 394). 

20 

In certain embodiments, the two network mediums are of the same type. 
For example, as depicted in FIG. 2, the 1394 serial bus 1 14 using the HTTP/IP 
interface protocol is connected by a proxy 1 16 to the Home Automation neutral 
118 (e.g., X10). By using the proxy 1 16 as HTML/HTTP/CTP/IP/1394 proxy for 

25 VCR-Commands/AVC/FCP/1394, to interface between HTML/HTTP/TCP/IP 
and X10 protocols, DVCR 120 is also accessible on the network 100. In 
certain other embodiments, a network can comprise two network mediums of 
dissimilar types, e.g., a 1394 Serial bus and Ethernet. Therefore, in certain 
embodiments of the invention, a proxy is used to interface two dissimilar 

30 medium types to from a single network. A discovery process, described 
further below, can be used for the discovery of devices that are powered on 
and connected to the network 100. Also, the same 1394 bus can be used 
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without need for a bridge box. 

As depicted in FIG. 2, devices 11 including DTV 102, DTV 103, PC 105, 
DVCR 110, DVD 108, DSS-NIU 104 and DVCR 120 represent devices that are 
5 currently connected to the network 1 00 comprising a 1 394 network. A client- 
server relationship exists among the attached devices, with the DTV 102 , DTV 
103 and PC 105 typically behaving as clients and devices DVCR 110, DVD 
108, DSS-NIU 104 and DVCR 120 behaving as servers. 

10 A typical 1394 network comprises interconnected devices such as a 

collection of appliances including server devices offering one or more services 
to be controlled (e.g., DVCR 100 as an MPEG video recording and replay 
sen/ice), and client device offering a user interface (Ul) service (e.g., DTV 102) 
for controlling the server devices. Some appliances (e.g., DTV 1 03) can have 

15 both services (e.g., MPEG decode and display capability) to be controlled, and 
a Ul controller capability. According to an aspect of the present invention, 
methods and systems including protocols, document description, image 
compression and scripting language standards from technologies utilized in the 
World Wide Web standard (Web model) are used to implement t a 1394WEB 
20 user-to-device control model in the network 100. The Web model is a 
client/server model. The controlled server device (service) comprises a Web 
server and the controller client device (i.e., a device capable of displaying a Ul) 
comprises a Web client including a GUI presentation engine, described further 
below, such as a Web browser (e.g., Explorer J, NetscapeJ, etc.). 

25 

<User Device Control> 

FIG. 4a shows a server device such as the DVCR 1 10 replaying MPEG 
video to a client device such as the DTV 102 in a network 1,00 according to the 
present invention, wherein the DTV 102 can display a user interface. The 
30 DVCR 110 includes Web server hardware and software and the DTV 102 
includes Web browser software. A user can utilize the DTV 102 to request 
that the DTV 102 display a user interface based on the device information 202 
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contained in the DVCR 1 1 0 or based on the device information 204 contained 
intheD7V102. For example, the user can utilize a browser 200 in the DTV 
102 to display an HTML control page GUI 202 contained in the DVCR 1 10 or 
an HTML control page GUI 204 contained in the DTV 102. Each page 202, 
5 204 includes graphical user interface description information in HTML, wherein 
the browser 200 reads that information to generate a graphical user interface. 
Each page 202. 204 represents the Control Interface of the Applications 206, 
212. respectively. Each page 202, 204 can include a hierarchy of pages to 
represent a corresponding application control interface. 
10 Each GUI 202 and/or 204 includes active control icons and/or buttons 

for the user to select and control devices currently connected to the network 
100. If. for example, the user selects a PLAY button in the GUI 202 of the 
DVCR 110 displayed by the browser 200 on the DTV 102. a hyperlink message 
is returned to the DVCR 110 Web server and directed to an application 
15 software 206 (e.g.. MPEG Record/Replay Service Application Software) in the 
DVCR 1 10 for operating a DVCR hardware 208. In one example, an MPEG 
video stream source 208 in the DVCR 110 transmits an MPEG video stream 
to an MPEG vide decode and display system 210 in the DTV 102 for display 
under the control of application control software 212 in the DTV 102. The 
application software 206 in the DVCR 1 10 also sends information back to the 
application software 212 in the DTV 102. including e.g. an acknolwdgement 
if the operation is successful, or an altered or different: control GUI 202 to the 
DTV 1 02 indicating status to the user. There can be further communication 
between the application softwares 206 and 212 e.g. for setting up a 1394 
isochronous video stream connection for video stream service. 

FIG. 4b shows another example architecture diagram of a server device 
communicating with a client device capable of displaying a user interface, in 
a network 1 00. The server device such as DVCR 1 1 0 replays MPEG video 
to the client device such as the DTV 102 in the network 100, wherein the DTV 
102 can display a user interface. 



Communication Protocol> 
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In an embodiment of the invention, the communication protocol between 
devices in the network 100 is based on the Hypertext Transfer Protocol (HTTP 1.1), 
an application-level protocol for distributed, collaborative, hypermedia information 
systems. HTTP is a generic, stateless, object-oriented protocol that can be use for 
5 many tasks. A feature of HTTP is the typing and negotiation of data representation, 
allowing devices to be built independently of the data being transferred over the 
network 100 to which the devices are connected. 

<GUI Description Language> 
10 The description document language for defining various GUIs 202, 204 

can be e.g. HTML, version 4.0. the publishing language of the World Wide Web. 
HTML supports text, multimedia, and hyperlink features, scripting languages 
and style sheets. HTML 4.0 is an SGML application conforming to 
International Standard ISO 8879 - Standard Generalized Markup Language. 

15 

<lmage Compression Formats> 

To display images, three still image graphics compression formats 
specified by the HTML specification are utilized in the 1394WEB network 100 
for ICON, LOGO and other graphics. The still image graphics compression 
20 formats are: Graphics Interchange Format (GIF89s) , Progressive Joint 
Photograhic Experts Group (JPEG) and Portable Network Graphics (PNG). 
Table 1 shows the differences in capabilities between the three different still 
image graphics compression formats. 
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<Table 1> 





PNG 


Progressive 
JPEG 


GIF89a 


Color Depth 


48 bit 


24 bit 


8 bit 


uoiors oupponeo 




16.7 million 


256 


rormais oupportea 


Raster, Vector 


Raster 


Raster 


Compression 
ocneme 


LZ77 derivative 


JPEG 


LZW 


Transparency 


Per Pixel for Grayscale 
& RGB, 

rer uoior tor indexed, 
zoo levels 


No 


Single Color, 
2 levels (Binary) 




res 


v/_ 

Yes 


Yes 


Scalable 


No 


No 


No 


Animation 




No 


Yes 


Lossless 
compression 


100% 






Truecolor 


48 bits 






Grayscale 


16 bits 






Indexed-color 


Yes 






Gamma Correction 
(light intensity) 


Yes 






Chromaticity 
Correction 


Both 






Searchable Meta- 
Data 


Yes 






Extensibility 


Yes, chunk encoded 







<Scripting Language> 

Further, the Web scripting language, ECMA-Script-262, is utilized to 
provide a means for visually enhancing the GUI Web pages 202 as part of a 
Web-based client-server architecture. The scripting language is a 
programming language for manipulating, customizing, and automating the 
facilities/services of the devices. The user interface 200 provides basic user 
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interaction functions, and the scripting language is utilized to expose that 
functionality to program control. The existing system provides the host 
environment of objects and facilities completing the capabilities of the scripting 
language. The web browser 200 provides the ECMA-Script host environment 
5 for client-side computation including, for example, objects that represent 
windows, menus, pop-ups, dialog boxes, text areas, anchors, frames, history, 
cookies, and input/output. 

The web browser 200 provides the host environment for the EXMA- 
10 Script-262, and the host environment supports attaching scripting code to 
events such as change of focus, page and image loading, unloading, error and 
abort, selection, form submission, and mouse actions. Scripting code is 
included within the HTML pages 202 and 204 and the displayed page is the 
browser 200 includes a combination of user interface elements, and fixed and 
15 computed text and images. The scripting code responds to user interaction 
without need for a main program. 

<Client Device Specification> 

In one example, the specification for a 1394WEB client browser 200 

20 includes HTTP1.1 specification, wherein section >8. 1.2.1 Negotiation' of the 
HTTP1.1 specification regarding connection persistence is modified such that 
an HTTP1.1 client device such as e.g. the DTV102 expects a connection to 
server device such as e.g. the DVCR 110 via the 1394 to remain open, 
because the persistent connection in 1394WEB user control allows full status 

25 reporting from the server device (DVCR 110) while the GUI 202 and/or 204 
remains visible in the browser 200 of the client device (DTV 102). The HTTP 
connection remains open (HTTP spec RFC 2068) wherein a client that 
supports persistent connections may "pipeline" its requests (i.e., send multiple 
requests without waiting for each response). A server must send its 

30 responses to those requests in the same order that the requests were received. 
This allows the web browser 200 to pipeline requests to the DVCR 1 10 which 
the DVCR 110 can then satisfy later with e.g. status responses such as Now 
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Playing, Now Recording, Rewind Finished, Tape Broken, Etc. Other example 
implementations include e.g. the control page from the DVCR 110 can contain 
a request to loop on the DVCR 100 request of GUI description 202. 

5 The GUI presentation engine 200 is utilized in the client device such as 

the DTV 102 to interpret GUI descriptions 202, 204 written in the HTML4.0 
document description language and the associated specifications (below), and 
to create the graphical form for display to the user. The GUI presentation 
engine 200 includes the following e.g. attributes: (1) window (GUI) minimum 

10 default size of e.g., H0x640 pixels (480x640 where 480 vertical, 640 horizontal). 
This default size is to insure the intended appearance in the GUIs 202, 204 is 
transferred to the user in the browser 200. The transferred GUIs 202, 204 are 
displayed in a window 480x640 pixels or magnified larger with the same aspect 
ratio unless otherwise directed by the user; (2) still image compression 

15 formats: e.g., GIF89a, JPEG, and PNG; (3) style sheet formats and fonts: e.g., 
CSS1 and CSS2; (4) fonts such as the following e.g. built-in fonts are 
required for the client device to free simple server appliances from having to 
support such fonts. Minimum one font from each generic Latin family can be 
selected: e.g., Times New Roman, from 'serif family; Helvetica, from 'sans- 

20 serif family; Zapf-Chancery, from 'cursive' family; Western from 'fantasy' 
family; and Courier from 'monospace' family. Other fonts can also be utilized; 
and (5) scripting language e.g., ECMA-262. Examples of the GUI 
presentation engine 200 include Web browsers such as Explorer J and 
NetscapeJ configured/customized as desired. 

25 

<Server Device Specification> 

One or more of the server devices (e.g. a 1394WEB network, controlled 
appliance Web server such as the DVCR 110), include the following six 
enumerated components: 

30 

(1) HTTP1.1 web server protocol, with section >8.1.2.1 Negotiation' 
of the HTTP1.1 specification regarding connection modified such that an 
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HTTP1.1 server device (e.g. DVCR 110) assumes that a HTTP 1.1 client device 
(e.g., DTV 102) intends to maintain a persistent connection with the server 
device. The persistent connection in the 1 394WEB network 100 allows full 
status reporting from e.g. the server device DVCR 110 to the client device 
5 DTV 1 02 while the GUI 202 of the DVCR 1 1 0 remains visible in the browser 
200 of the DTV 102. Further, a method using HTTP conditional GET to obtain 
the latest status of server devices can be used. Whenever the user returns 
to the home network directory or causes it to be refreshed, the browser 200 
redisplays the page in its entirety. This is necessary because the HTML that 

10 underlies the home network directory may have been regenerated if a device 
has been added to or removed from the network 100. It is also possible for 
device icons to be updated to reflect changes in their device's operating state. 
As such, browsers implemented by EIA-775.1 devices utilize HTTP "conditional 
get" requests to determine whether or not fresh copies of web pages or 

15 graphics should be retrieved from the server. 

(2) Device home page GUI descriptions 202, 204 written e.g. in 
HTML4.0, include file e.g. icon.htm, name.htm, logo.htm, index.htm, gif files, 
etc.. The file index.htm is referenced by HTML links included in device icon.htm 

20 and name.htm HTML files, wherein index.htm can be optionally named e.g. 
"INDEX.HTML" or "INDEX.HTM". File named INDEX.HTM is not required to 
be a standard name because the ICON.HTM and NAME: HTM are made with 
hyperlinks to the 'INDEX.HTM', therefore the name is arbitrary. ICON.HTM and 
LOGO.HTM reference the actual graphics files in the same device e.g. 

25 LOGO.GIF and ICON.GIF. The descriptions 202, 204 are accessible by the 
devices (e.g., HTTP devices) in the network 100. To guarantee a desired 
appearance, the control GUI design can be for a default GUI size of e.g. 
480x640 pixels. For example, a transferred GUI 202 can be displayed in a 
window of 480x640 pixels in the browser 200 or magnified larger with the same 

30 aspect ratio unless otherwise directed by the user. 

(3) At least two device ICON files are provided to represent the device 
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in a top-level network page 220 (FIGS. 5-6) in the browser 200 showing 
information about the devices connected to the network. An ICON can 
comprise a graphic file type (e.g. GIF, JPG or PNG) and named ICON.HTM. 
In one example, ICON.HTM(DVCR) references the INDEX.HTM file in the 
5 HTML page 202 and ICON.HTM(DTV) references the INDEX.HTM file in the 
HTML page 204. The top-level link for the control pages (e.g., INDEX.HTM) 
of the device can be ICON.HTM. The browser 200 places the icons and links 
therein) of a plurality of devices in the network 100 in the top-level HN directory 
page 220 for service discovery by the user. Then user clicks the ICON 

10 displayed in the page 220 and the device page (e.g. INDEX.HTM in page 202) 
is fetched. The default displayed HN directory is the top-level discovery page. 

A number of additional and different graphic icons can also be utilized, 
for example, to represent device status, user configured preference or 
manufacturers formats which may be substituted for the icon graphic. In a 

15 discovery process described further below, ICONs from the devices 
connected to the network 100 are collected together and displayed in the top 
level network devices page 220 for selection by a user. An example device 
ICON specification comprises: File name ICON.HTM accessible by the HTTP 
server (files names are in a directory, file space, accessible by the web server 

20 so that they can be retrieved and forwarded over the network to the browser); 
Graphic file type such as GIF, JPG or PNG; and Icon graphic with a 
maximum size of 70(V)x1 30(H) pixels. 

(4) At least two device LOGO files are provided to represent the 
25 device in the top-level network devices page. LOGO can comprise a graphic 
file type (e.g., GIF, JPG or PNG) and named LOGO. HTM. In one example, 
LOGO.HTM(DVCR) references the INDEX.HTM in the HTML page 202 and 
LOGO.HTM(DTV) references the INDEX.HTM in the HTML page 204. In 
one version, the top-level link for the control pages (e.g., INDEX.HTM) of the 
30 device can be LOGO.HTM. All device logos are placed in the top-level HN 
directory page 220 for service discovery by the user. Then user clicks the 
LOGO displayed in the page 220 and the device page (e.g. 202) is fetched. A 
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number of additional and different graphics for manufacturer services can be 
substituted for the logo graphic format . According to the discovery process. 
LOGOs from devices connected to the network 100 are collected together and 
displayed in the top level network devices page 220 for selection by a user. 
5 An example device LOGO specification comprises: File name LOGO. HTM 
accessible by the HTTP server; Graphic file type such as GIF, JPG or PNG; 
and logo graphic maximum size of about 70(V)x1 30(H) pixels. 

(5) At least one device NAME is provided to represent the device in 

10 the top-level network devices page. NAME comprises TEXT in an HTML file 
NAME. HTM. This text can also reference control pages (e.g., 202). This is 
a top-level link in the discovery page to the control interface of the device. 
The text provides a way to distinguish identical devices whereby for e.g. two 
identical DTVs can be distinguished by adding NAME text 'Bedroom TV and 

1 5 'Family Room TV. The text can comprise a few words to clearly represent the 
device type e.g. DVCR or DTV. According to the discovery process, NAMEs 
from devices connected to the network are accessed along with 
corresponding ICONs/LOGOs and displayed in the top level network devices 
page 220 under the ICON/LOGO. An example NAME specification 

20 comprises: File name NAME.HTM accessible by the HTTP server; Text 
unspecified, such as, with Font size 10, two lines of text can be displayed 
under the corresponding ICON/LOGO. Therefore, for example the space size 
for the NAME.HTM text can be 20 vertical by 130 horizontal to match the 
ICON/LOGO (70 vertical x 130 horizontal). As shown by example in FIGS. 

25 5-6, the format of the top-level Ul 220 can comprise a matrix of icons 
representing the functions of the networked devices to the user. The name 
representing the device (from name.htm) is placed under the icon (from 
icon.htm) from the same device. Logo (from logo.htm) may be placed e.g. in 
any vacant icon position. As the Top-level description 250 (described further 

30 below in conjunction with FIGS. 9a-c) is generated independently by Ul 
capable devices, the exact design need not be prearranged. The icon, logo and 
name maximum sizes can be prearranges to facilitate design of the GUI matrix. 
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(6) A device information summary home page description document 
written in HTML4.0 can be provided, named e.g. "info.html" or "info.htm", and 
made accessible by the HTTP server for the discovery process. A link can 
5 be provided to INFO.HTM information via control pages e.g. 202, 204. The 
device information summary homepage provides the user a device summary 
instead of the detailed control interface as shown in the device homepage. 
Table 2 shows device attributes text that are included and others that can be 
included. This table can be extended to included other attributes. 

10 

<Table 2> 







Device Name 


Device name (user configurable) 


Device Location 


Device location in home (user configurable) 


Device Icon 


Current Device ICON name 


Device Type 


Device type or category (VCR, DSS, TV, etc.) 


Device Model 


Device model 


Manufacturer 
Name 


Name of device manufacturer 


Manufacturer Logo 


Manufacturer Logo image name 


Manufacturer URL 


Device manufacturer's URL 


Stream Source 
Name Default 


Service: Default source device name for this 
Device's destination service 


Stream 

Destination Name 
Default 


Service: Default destination device name for this 
Device's source service 


Stream Source 
Attributes 


Type of service device can deliver (attributes and 
capability) 


Stream 

Destination 

Attributes 


Type of service device can receive (attributes and 
capability) 
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Table 2 includes device summary information such as Manufacturer 
Name, Manufacturer Logo image name, and can further include a 
Manufacturer URL for help if there is an available Internet connection to the 
5 manufacturers Web site. Table 2 can further include a user configurable 
Device Name and Device Location in the home. There can be several 
variations of the Device Icon representing different states of the device. The 
Device Icon attribute field includes the name of the current icon. Therefore, the 
device summary information page can provide immediate device state 
10 information to the user by displaying the icon representative of current state. 

Each device can include one or more services, e.g. video Stream 
Source or video Stream Destination. Each source capability has a 
complementing Default Destination capability and each destination capability 

15 has a complementing Default Source capability. This Stream Default Name 
entry can be used e.g. to automatically default the nearest DTV to be the 
destination when a DVCR is being controlled as source to eliminate having to 
select the DTV each time. A background cross-referencing of the Stream 
Default Name to 1394 address is provided. The video stream services are 

20 provided by the 1394 interface itself (not by Web model). As such there is a 
linkage of the default source or sink to the 1394 address mechanism. The user 
can access a device and select a name for default, which is then saved on the 
device. The device's software agent must find the 1394 address and 
parameters for the 1394 s/w to enable the default stream when required. 

25 

Using the Source and Destination service attributes, new 
server/services can be implemented while maintaining compatibility with 
existing host or device (nodes) and services. For example, if a new server 
device providing a new service is developed that is compatible with an existing 
30 server device, both the new and existing serviers can be added to the attribute 
list of the new node while maintaining compatibility with existing nodes using 
the existing server in the network 100. The user can select a compatible device 
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for purchase. These provide a user with "ABOUT' information to check 
capabilities of existing equipment e.g. prior to purchasing new equipment 
where compatibility is desired. 

5 <Network Operation> 

A discovery process for every device supporting the 1394WEB standard 
(e.g. devices capable of displaying a user interface) gathers device information 
from devices connected to the network 100 to generate the top-level user 
control page description for the home network, wherein each device is 

10 represented by a graphical icon reference and a textual name reference 
detailed above. The top-level description can include a default page for a 
presentation engine such as the browser 200, wherein the browser 200 collects 
the graphic images and names from the devices as it renders the network top- 
level graphical user interface 220 (GUI) displayed in the browser 200 as shown 

15 by example in FIGS. 5-6. The dynamically created top-level HN directory page 
220 is made the default page for the browser (first page displayed when the 
browser is launched). 

With reference to FIG. 4b, example operation steps include: (1) the 
20 browser 200 in device 102 is launched, (2) the browser 200 fetches and 
presents HN-Directory HTM (Top-Level Ul) from the page 204, (3) the browser 
200 fetches the HTM files icon.htm and names.htm from pages 202, 204 and 
presents in the Top-Level Ul, (4) the browser 200 fetches any graphics files 
(e.g., GIF) from pages 202, 204, and presents in Top-Level Ul, (5) the browser 
25 200 is then able to present the full HN_Directory page 220 (page 220 is made 
with hyperlinks to 'INDEX.HTM' files for different devices connected to the 
network 100), and (6) when a user clicks e.g. DVCR icon in GU! 220 to control 
the DVCR 110, . a corresponding hyperlink in the top-level page 220 to 
•INDEX.HTM' of the DVCR 110 is used to retrieve the 'INDEX.HTM' (top 
30 control page of DVCR) from page 202 in the DVCR 110. and present the 
DVCR control page to the user (e.g., if the frame that was clicked (e.g. the 
icon.htm frame) is not large enough, a graphic is presented in another copy of 
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the browser with full frame size). The user can then command and control the 
DVCR 1 10 using the control interface provided by 'INDEX.HTM' of the DVCR 
device 1 10 presented by the browser 200 in the DTV 102 

5 The name 'INDEX.HTM' is arbitrary because the ICON.HTM and 

NAME.HTM are made with hyperlinks to the 'INDEX.HTM'. However, 
ICON.HTM and LOGO. HTM reference the actual graphics files (e.g. 
LOGO.GIF and ICON.GIF) in the same devices. In one embodiment, 
LOGO. HTM can be optional if a logo for a device is optional. The 
10 HN_Directory HTML file can have a standard name so that it can be accessed 
from another device. 

FIGS. 5-6 show that the host device, such as a client device (e.g., 
DTV 102, HDTV1) or server device (e.g., DVCR 110) that generates and 

1 5 presents the top-level GUI page 220 can assume priority and use a larger size 
icon for the host device's icon, name, logo, etc. In one version, only devices 
with servers (services on offer) are displayed in the GUI 220 (a "Client device" 
comprises device with Client capability, where if it is only client then it is not 
displayed in the top-level GUI as there is no service to offer). The discovery 

20 process reads information from the 1394 address space data storage 
(configuration ROM structure), as defined in clause 8 of I SO/I EC 13213. 
Although called 'ROM' it is assumed that the address space is write-able to 
allow user configuration and modification of user relevant stored values. The 
contents of the configuration ROM and the discovery process are described 

25 further below. 

Device naming, addressing and discovery processes for home or local 
network control of consumer devices using Internet, Web and 1394 technology, 
can be different from the requirements and practice in the general Internet 
30 space. As such according to an aspect of the present invention for in home 
or local network control of consumer devices, special processes including 
device discovery, addressing and naming requirements are utilized. For 
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example, the home network must fully function without the presence of external 
communications and sen/ices, without a network administrator, and 
configuration must be fully automatic. User control can be in many cases 
entirely keyboard-less. Further, the IEEE1 394 protocol is utilized to provide 
5 a sophisticated interface including features that can be provide simple, efficient 
and superior discovery and configuration functions. 

<1394 Home Network> 

FIG. 7 shows a block diagram of a network 300 constructed in 

10 accordance with another embodiment of the present invention. To facilitate 
understanding, identical reference numerals have been used, where possible, 
to designate identical elements that are common throughout all the figures 
herein. As depicted in FIG. 7, a 1394 serial bus 114, described above, 
electronically connects multiple devices including server devices 14 (e.g., DVD 

15 108, DVCR 110) and client devices 12 (e.g., DTV 102) on the network 100, 
described above in reference to FIG. 2, wherein the devices communicate 
using the example layered interface model of FIG. 3 as described above. 

The network 300 is not restricted to using a 1394 serial bus, and, in 
20 alternative embodiments of the present invention, other bus types, such a 
Ethernet, ATM wireless, etc., can be used as the physical layer if they meet the 
particular throughput requirements of an individual network (e.g., a home 
network) . As depicted in FIG. 7, the network 300 includes several devices 
connected to the 1394 serial bus 114. In this example, the devices include a 
25 DBSS 104 for receiving transmission signal from a satellite 122 for subsequent 
display. Associated with the DBSS is a network interface unit ("NIU") which, 
among other things, provides an interface between the DBSS satellite 
transmission and the 1394 serial bus 1 14. A digital video device (DVD) 108 
is also connected to the exemplary network 300. The DVD 108 can be used 
30 to source digitally encoded videos for display on e.g. a digital television. Also 
.connected to the exemplary network 100 is a digital video cassette recorder 
(DVCR) 1 10, a digital TV (DTV)102. In this example, the DTV 102 provides 
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a human interface for the network 300 by employing browser technology to 
allow users to control and command for devices over the home network 300. 
A second DTV 103 provides another human interface for the network 100 by 
employing browser technology to allow users to control and command for 
5 devices over the home network 100. The DTVs 102 and 103 can provide 
human interfaces for the network 300 as each DTV comprises a screen for 
displaying HTML pages. However other devices having display capability can 
be used to provide human interfaces. Thus, in certain embodiments of the 
invention, a device such as a personal computer 105 (PC) is used to provide 
10 a human interface for a respective home network, as a PC 105 typically 
embodies a screen display unit. 

The 1394 serial bus 114 is depicted as using the HTTP/IP interface 
protocol, and preferably HHTP/TCP/IP, wherein IP provides packet format (a 

15 one-way write only model), TCP provides an error free version of IP (e.g., 
ensures packets arrive and in correct order), and HTTP provides 2-wa 
connection (packet to server will expect a response -a 'read' model). Certain 
devices can require other protocol interface types (e.g., TCP/IP, UPD/IP, 
FTP/IP.TELNET/IP, SNMP/IP, DNS/IP, SMTP/IP). In certain embodiments 

20 of the invention, a proxy 116 can be used to interface two networks using 
dissimilar interface protocols on their respective mediums which, when 
connected, comprise the network 300. ■ 

For example, as depicted in FIG. 7, the 1394 serial bus 1 14 using the 
25 HTTP/IP interface protocol is connected by a proxy 116 to the Home 
Automation network 118 (e.g., X10). By using the proxy 116 as 
HTML/HTTP/CTP/IP/1394 proxy for VCR-Commands/AVC/FCP/1 394, to 
interface between HTML/HTTP/TCP/IPand X10 protocols, DVCR 120 is also 
accessible on the network 300. 

30 

In this embodiment, the network 300 can be connected to an external 
network 119 of dissimilar type (e.g., Ethernet) to the 1394 Serial bus, via a bus 
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121 . A proxy 1 17 is used to interface the two dissimilar medium types. For 
communication between the addressing scheme of the external network 119, 
and the addressing scheme of the network 300, the bridge 117 comprises a 
Network Address Translation (NAT) boundary. This technique can be utilized 
5 for company LAN's and is a 'divide and conquer* approach to the complex 
problem of satisfying various network's differing IP address requirements and 
prevents 'running out of IPV4' addresses. The external network can include 
e.g. CABLE-TV network 115 via Ethernet to the telephone e.g. ADSL), 
providing broadband connection to the Internet and WWW. The Ethernet 1 1 9 

10 provides the bridge function to the external network. The bridge 117 or 
Ethernet 119 may provide the NAT address conversion function. If the Ethernet 
is to provide local private (to home only) addressing (e.g. as defined by then 
IETF standard RFC 1918) then the NAT function is in the Ethernet 119. 
Existing cable modems are set up with a global address and also Internet 

15 global address for the PC on the Ethernet (in this case the NAT is in the bridge 
117). 

<IP Name/Address Configuration> 

The aforementioned device naming, addressing and discovery 

20 processes for the network 300 are now described. For device naming, point 
and click Web operation (e.g., using GUI/Web) does not require name services 
(DNS, Domain Name Service). The Web GUI provides an abstraction layer, 
and the addresses are hidden as hyper-text links invoked by user 'clicks' to 
active GUI areas (e.g., buttons). Any change to the devices in the local 

25 network 300 causes the top-level discovery GUI page 200 (FIGS. 5-6) to be 
recreated by the browser 200 (FIGS. 4a-b) representing the status of the 
devices in the network 300 at that time and by default presented to the user 
for immediate use. 

30 For device to device control a different look-up service is utilized for 

more than names (e.g., service look-up and application look-up). As such, 
DNS may not provide the necessary features for device to device control. 
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However, a device (e.g., a 1394 connected PC) can access a DNS service as 
usual. DNS is not required for discovery or operation of devices/services 
within the home, but DNS (name to address) look-up service is required for 
external accesses e.g. from a PC. When a name e.g. "www. yahoo.com " is typed 
5 in to a Browser then look up take place for the IP address of the Yahoo 
computer, i.e. 216.32.74.52, because the Internet (even home internet) 
operates with addresses. 

For a 775WEB Ul device which includes an agent for generating the HN 
10 top-level directory GUI description and also includes access to the special 
company web server e.g. homewideweb.com (IP address), can also have the 
DNS address knowledge. The DNS server computer IP address can be any 
IP address under the control of the manufacturer. Effectively the DNS address 
is built-in to the device (or can be updated if the agent is made to be update- 
1 5 able and is later updated). 

For device addressing, in one embodiment of the invention, utilizing 
fixed IP addresses from a large address space can afford the simplest and 
most reliable network configuration, and the readily accessible ROM data 
20 space in the1394 interface allows utilization of fixed IP addresses therein. In 
another embodiment of the invention, non-fixed IP (dynamic) addresses can 
be utilized, wherein an abstraction layer (e.g., name or look-up mechanism) 
is employed to retain pre-organized communications 

25 For IP address configuration, the following protocols can be utilized: (1) 

Dynamic Host Configuration Protocol (DHCP) with DHCP servers and DHCP 
clients, (2) DHCP clients resort to auto-configuration (DHCP server not 
present), and (3) preferably, FWHCP (Fire-Wire Host Configuration Protocol) 
server agent(s) and FWHCP clients, described further below. The auto- 

30 configuration in (2) above is that proposed as an IETF Draft "draft-ietf-dhc-ipv4- 
autoconfig-04.txt". 
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DHCP requires support of the BOOTP/UDP protocol, and replicates 
what is done within the 1394 specification and provides features such as lease 
time and dynamic addressing. Typical DHCP requires management by an 
administrator and must be configured and adapted to the network requirements 
5 of mass manufactured consumer electronics (CE) appliances where, for 
example, multiple identical CE appliances with DHCP server built-ins must be 
considered. 

The 1394 technology provides 'Plug-in* or 'Power-up* reset and following 
10 'Self-ID' sequences, well suited for network configuration. Further, the 1394 
specification provides a built-in 'ROM' address space well suited for storage 
of, and access to, configuration data (e.g., IP addresses). As such, in a 
preferred embodiment of the invention, an IP address configuration agent 
(FWHCP) and discovery page for user control of 1394 devices are utilized. 
15 FWHCP provides IP address configuration for 1394WEB and 1394 devices. 
The purpose and result of FWHCP is similar to DHCP (i.e., a server to identify 
and assign the local IP addresses), but in operation FWHCP uses data in 
1394-address space and 1394 commands. FWHCP provides IP address 
configuration of 1394WEB devices on the 1394 network avoiding collisions with 
20 devices on adjacent attached networks other than 1394. Devices are 
manufactured with a built-in IP address from the 10.x.x.x range. In the unlikely 
event of a collision, FWHCP sets a new IP address and saves it in the device. 

DHCP/Auto-configuration can be utilized for devices on networks other 
25 than 1394. DHCP protocol provides client "requested IP address". 
Preferably, the requested IP address space is selected from the upper part of 
the 24 bit RFC1918 range (10.128.1.1 to 10.254.254.254). By choosing part 
of the allowed private address range for 1394 IP addresses and another part 
for other configuration methods (e.g., DHCP and DHCP/Auto-Configuration) 
30 then compatible and non-interfering addresses are generated for a 
heterogeneous network and allow FWHCP and DHCP to coexist. 
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While choice of non-overlapping IP addresses for 1394 and adjacent 
networks is desirable, the heterogeneous network using FWHCP will configure 
successfully even if they do overlap. Also, DHCP clients check their assigned 
IP address with a test ARP message before using it. As such, different 
5 address configuration methods can coexist successfully. 

<Network Scenarios and Address Management 

Referring to FIG. 8, an example process according to the present 
invention for communication between a 1394 network (e.g., network 300) and 

10 a non-1394 network (e.g., Ethernet 119) for IP address configuration is 
described. In this case the 1394 network 300 utilizes FWHCP configuration 
and the non-1394 network 119 utilizes DHCP configuration or other method. 
Generally, 1394 devices (such as DTV and DVCR in FIG. 7) do not support 
DHCP. The 1394 DEVICE-3, for 1394 network to non-1394 network 

15 communication, includes an IP address in the 1394 ROM space and provides 
support for FWHCP for a 1394 device. The DEVICE-3 further includes means 
for supporting the configuration mechanisms on the non-1394 network, and 
maintains an extension data leaf in the 1394 ROM space for IP addresses of 
devices on the non-1394 network. As such, configuration processes (e.g., 

20 FWHCP for top-level Ul description generation) on the 1394 network 300 can 
include use of IP addresses on the non-1394 network by selecting IP 
addresses from the extension data leaf. The non-1 394 network configuration 
operates to provide the IP addresses for the 1394 extension data leaf. 



25 According to the discovery process (agent), 1394 specification 'plug-in 1 

reset and self-ID is utilized for configuration and can be used for IP address 
configuration. Preferably, fixed IP addressing is utilized for home networks, 
however dynamic IP addressing can also be utilized;. DNS is not required 
within 1394WEB control because a top-level GUI description is created with 

30 hypertext-links that use IP addresses rather than names. Preferably, the IP 
configuration agent (FWHCP) for the 1394 network is utilized for IP 
configuration using 1394 ROM data and 1394 commands, however DHCP can 
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also be utilized. FWHCP utilizes lower half of RFC1918 10.LH.X.X addresses 
and other home networks (not 1394) use upper half 1 O.UH.X.X. Preferably, 
the FWHCP server agent is built-in to any device that can be a client (control 
initiator). Where there are several client devices connected to the 1394 
5 network, only the client device with the highest Global Unique Identification 
(GUID) operates. GUID comprises a number built-in to the interface. If 
there are multiple FWHCP agents available on the 1394WEB network then 
there is an initial self-election process to determine the one that will operate 
and all others remain quiet. The highest GUID will operate. In other versions, 
10 highest bit-reversed-GUID can be used. 

A device interfacing to a non-1394 network supports a ROM extension 
leaf of IP addresses on the non-1394 network. This allows inclusion of the IP 
addresses on the non-1394 network in the 1394 top-level GUIs (e.g., FIGS. 4a- 
15 b, GUIs 202, 204). Control data bits in the 1394 ROM space are used to 
control the operation of three configuration agents: (1) 1394 SelfJD count, 
(2) IP configuration FWHCP, and (3) Ul description generation described 
further below. 

20 Initially 1394 Self-ID count discovers the existence of devices. After a 

bus reset (caused by power up/down or device attachment/detachment) 1394 
software in the device observes the automatic configuration process (1394 self- 
ID cycles) for the purpose of counting the number devices. This is a normal 
part of 1394 software for any 1394 device. Then, IP Configuration FWHCP 

25 (the one self -elected FWHCP) probes the discovered devices and checks their 
built-in IP address. Discovered duplicate (colliding) IP addresses are disabled 
and a new address is assigned to the device. Then, Ul description generation 
agent (Ul or other devices), reads all 1394WEB device IP addresses and 
generates a top-level device directory Graphic User Interface file in HTML of 

30 top-level icon pages from each device later rendered by a Web browser for 
User discovery of devices for control. 
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According to the present invention each device in the 1394 network 400 
can generate its own top-level network Ul description 250 (FIG. 9c). The Ul 
description 250 is used by a presentation engine such as the browser 200 in 
a client device to generate and display a top level directory page such as page 
5 220 in FIGS. 5-6. After the 1394 Self-ID agent has enumerated all devices 
connected to the 1394 network 300, the top-level Ul description 250 is 
generated separately by all Ul devices (and non-UI devices as desired). A 
device (e.g., DTV) can select a more prominent (e.g., larger) icon to represent 
that device, and make the entire GUI 220 with a different look. This technique 

10 provides substantially more reliable operation than a centrally generated GUI 
for operation of all device, because each device can generate its own Ul 
description 250 and display a GUI (e.g., top level page 220) based thereon 
without dependence on another device. In each Ul description 250, device 
icon and logo image files of the devices currently connected to the network 300 

15 are referenced by icon and logo HTML 'pages' and name text wrapped in an 
HTML page (ICON.'Graphic' referenced ICON.HTM is in pages 202 and 204 
which also include the control pages for the device; Fig. 5 below also shows 
the ICON.HTM, LOGO. HTM and NAME.HTM in a top-level directory page). 
HTML frames are used to create the top-level directory Ul description 250 for 

20 network devices in each network device as desired. 

As such, advantageously, a useful layer of abstraction is provided to 
allow use of alternative file names and types for e.g. identification graphics in 
the network devices without need for change in the top-level description 250 

25 generated in each device. The name text is also placed in an HTML description 
202, 204 (NAME.HTM is in pages 202, 204), allowing a user to configure the 
name text at a device e.g. DTV to change to e.g., DTV-BED2 through one of 
the device GUI pages 220. As such, the page 220 is displayed as the 
Browser is launched after a reset. The user sees and clicks DVCR ICON 

30 graphic, whereby DVCR top level control GUI 202 is fetched (with Play' 
button etc.). User clicks one of the buttons e.g. "Configure Device NAME" 
which is another GUI (of hierarchy of control pages for DVCR) with a large 
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selection of different names. 

User clicks one name out of the lists of names provided e.g. "Master 
Bedroom DVCR". 

Software on the device changes the file names so that the file named 
5 NAME. HTM contains the text "Master Bedroom DVCR" (the old default 
NAME. HTM file that contained DVCR is changed to some other name). 

Appearance of the GUI 220 is more stable in the event of 'bad citizen' 
devices having too much or oversized text or oversized logos. In this case the 
10 frames isolate the problem and prevent the bad items from adversely affecting 
the appearance of the entire top-level GUI 220. 

<Device Discovery Architecture> 

Referring to FIGS. 9a-c, 10, 11 example functional blocks and 

15 connections to data and control bits and flowchart of an embodiment of a 
system architecture 400 for the aforementioned discovery process are shown. 

The system 400 comprises five primary elements: (1)1394 non-volatile 
memory space (IEEE1212R ROM) 402 for configuration data and control data 
bit storage; (2)1 394 Device Discovery Agent (1 394DDA) 404; (3) IP Address ' 

20 Configuration Agent (FWHCP) 406; (4) Ul Description Generation Agent 408; 
and (5) GUI Generation and run-time environment 410 (e.g.. Web Browser 200 
in FIG. 2). Further, FIG. 10 shows an example flow diagram for the DDA and . 
FWHCP agents in system 400 operating in connection with the functional 
blocks in FIGS. 9a-c. And, FIG. 10 shows an example flow diagram for the 

25 UIDGA agent in system 400 operating in connection with the functional blocks 
in FIGS. 9a-c. 

Referring to FIGS. 9a and 10 all devices include the 1394 device 
discovery agent (1 394DDA) 404 to enumerate the devices on the 1 394 bus, 
30 after a reset, and to write the value into the local 1394 ROM space 402 for 
communicating the value to other functional agents (steps 500, 502). For 
synchronizing (inhibiting) commencement of other configuration agents, the 
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1394DDA agent 404 also sets the 'configuration operating 1 control bits . The 
discovery agent/mechanism can use means, other than the ROM space, to 
communicate information between the configuration agents that are local to 
one device and where the information does not need to be seen by other 
5 devices. 

<1394 ROM Data in all Devices> 

All devices in the network 300 include the following information relevant 
to the discovery and IP address agents 404 and 406, respectively, for 

10 the1394WEB in the 1394 configuration ROM 402: (1) Built-in 64 bit GUID 
(Global Unique ID, in 1394 specification); (2) Built-in IP address from the RFC 
1918 private address space in the range '10.1.1.1' to '10.127.254.254'. 
Manufacturers can select a value from the GUID such that chance of collision 
is minimized. The upper portion of the private address space (i.e., 10.128.1.1 

15 to 10.254.254.254) is reserved for devices on bridged networks; (3) Assigned 
IP address in the range '10.1.1.1' to '10.127.254.254' (assigned by operating 
FWHCP agent 406); (4) IP address extension leaf for IP devices on bridged 
networks; (5) Assigned Count of 1 394 devices (assigned by 1 394DDA agent 
404); (6) Control/status bits to indicate Configuration-in-Progress 

20 Synchronization control for 1394 Device Discovery Agent 404, and to indicate 
IP-Address configuration (The control bits indicate the configuration is in 
progress and therefore the values, in ROM data other than the control bits, for 
1394DDA and IP address are not checked or not written and therefore should 
not be used). The bits further indicate which IP address is valid (assigned or 

25 built-in), and whether an FWHCP server agent 406 is present in the device; (7) 
HTTP web server to allow files in the device's file space to be accessed 
remotely; and (8) device information 202, 204 including actual 'icon 1 , 'name' 
and 'logo' HTML files, and other referenced graphic files accessible through 
the Web Server. The above summarized information is detailed in the 1394 

30 ROM space description below. 

<IEEE 1212 Configuration ROM> 
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The content of the general 1394ROM structure 402 is specified in 
IEEE1212r, IEEE1212 and IEC61883. The ROM structure 402 is a hierarchy 
of information blocks, wherein the blocks higher in the hierarchy point to the 
blocks beneath them. The location of the initial blocks is fixed while other 
5 entries are vendor dependent, but can be specified by entries within the higher 
blocks. 

Table 3 shows the BusJnfoJ3lock and Root_Directory of the configuration 
ROM 402. The first byte of each entry is known as a key and identifies the 

10 type of entry. The following can be implemented in the configuration ROM of 
all devices making use of the EIA-775 specifications, including display devices 
such as DTVs and source devices such as DVCRs, STBs, etc. There may be 
several other structures required based on other protocols to which each 
device conforms. Table 3 includes information for a device which also complies 

15 with the IEC61883 protocol. The Root_directory contains pointers to a 
ModeLDirectory and three UnitJDirectory entries (IEC61883, EIA-775 and 
1394WEB), to indicate that the device supports EIA-775 as well as 1394WEB 
protocols. The Root directory entries are useful to other 1394 devices to 
discover the protocols and software (also called services) supported by this 

20 1394 device. 

<Table 3> 



Offset (Base address FFFF F000 0000) 
Busjnfo_block 
Offset 



04 00 16 


04 crcjength 


rom_crc_value 


04 04 16 


"1394" 


04 08 16 


flags Reserved 


cyc_clk_acc 


Max_rec feserved 


04 0C 16 


node_vendorjd 


Chip_id_hi 


04 10 16 


chipjdjo 
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Wherein, 04 0C 16 and 04 10 16 are also known as the 64 bit GUID or 
Global Unique ID. 

Root_directory 
Offset 



04 14 16 


rootjength 


CRC 




03 18 


Model_vendor_id 




81 „ 


Vendor_name_textual_descriptor offset 




oc 16 


Node_capabilities 




8D 16 


Node_unique_id offset 




D1 16 


Unit_Directory offset (IEC 61883) 




D1 16 


Unit_Directory offset (EIA-775) 




D1 16 


Unit_Directory offset (1394WEB) 




Optional 


XX XX-jg 


C3 16 


Model_Directory offset 



The IEC_61883 unit directory is shown in Table 4. This directory is 
10 referenced by the UnitJDirectory offset, in the Root Directory (e.g., 
Root_directory table). In the Unit_SW_Version field, the least significant bit 
specifies AV/C (0) as specified in IEC 61883. 

<Table 4> 
15 Unit_Directory (IEC_61883) 



Directory length 


CRC 


12 16 


Unit_Spec_ID (1394TA = 00 AO 2D 16 ) 


13 16 


Unit_SW_Version (first pass key = 01 16 ) 




«possibly other fields» 







The EIA-775 Unit Directory is shown in Table 5. The following EIA-775 



WO 01/37581 PCT/KR00/01330 

40 



specific information appears in the EIA-775 Unit Directory. 



<Table 5> 



directory length 


CRC 


12 I6 


Unit_specification_ID (EIA-775 = 005068 16 ) 


13 19 


Unit_software_version (010100 16 ) 




«possibly other fields» 







The Unit_specificationJD specifies the identity of the organization 
responsible for the architectural interface of the device and the specification. 
In this example case, the directory and identity vaiue=005068 16 refers to the 
EIA as the responsible body and the EIA-775 control architecture specification 
10 The Unit_software_version designates EIA-775 revision level supported 

by the device. The format is shown in Table 6. 



<Table 6> 


First octet 


01 , e 


Second octet 


Major Version Number (currently 01 16 ) 


Third octet 


Minor Version Number (currently 00 16 ) 



15 The 1394WEB Unit Directory is shown in Table 7. The following 

1394WEB specific information appears in the 1394WEB Unit Directory. 
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<Table 7> 



directory length 


CRC 




i Unit soecification ID M394WEB = OOXXXX ^ 


13 16 


Unit_software_version (010100 16 ) 






38 16 


Discovery _control_bits 


39 16 


Assigned_Count_of_1 394_devices 


3A 16 


IP_Address_Built_in 


3B 16 


IP_Address_Assigned 




IP_Address_Extension Leaf 


~16 


«possibly other fields» 



The Unit_specificationJD specifies the identity of the organization 
5 responsible for the architectural interface of the unit and the specification. In 
this example case the directory and identity value=00XXXX 16 refers to the 
responsible body and the 1394WEB control architecture specification. 

The Unit_software_version designates the 1394WEB revision level 
10 supported by the device. The format is shown in Table 8. 



<Table 8> 


First octet 


01 16 


Second octet 


Major Version Number (currently 01 16 ) 


Third octet 


Minor Version Number (currently 00 16 ) 



<Discovery_control_bits (38 16 )> 
1 5 Key value (38, 6 ) permitted by the IEEE1212R specification section 8.8 

for the private use by the owner of the directory and architecture is used for the 
Discovery_control_bits immediate value. 
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<Table 9> 











FWHCP 


Configuration Which IP 










Server 


operating. Do not use address? 










Agent 


(if True) 


X 








Yes=1 


1394 Dev. IP- Assignd_ 
Count Address 1 Built- 

in_0 


31 


6 


5 


4 


3 


2 1 0 (LSB) 



5 These are control bits in 1394 ROM space 402 accessible by local and 

remote device. The contra! bits are used by the IP address configuration agent 
406 and the User Interface description generation agent 408 as described 
further below. 



10 In one embodiment of the invention, said control bits provide the 

following information: 

Bit 0 - Which IP address - Indicates which IP address is used or is in- 
use i.e. the Bulit-ln address (=FALSE) or Assigned Address (=TRUE). This is 
set by the operating IP configuration agent FWHCP 406. 

15 Bits 1,2- Configuration Operating Do not use - When set indicate that 

the 1394 device discovery and also, seperately, the IP configuration agents 
404 and 406, respectively, are operating and therefore the values referred to 
are invalid as they can change or are not yet written. These bits are set by the 
local (device) 1 394DDA agent 404. The1 394DDA agent 404 clears the 1 394 

20 Dev. Count bit and the operating FWHCP agent 406 clears the IP-address bit. 

Bit 3 - Presence of FWHCP Server Agent 406 B Is set if the device has 
an operable FWHCP agent 406. This bit and GUID are used by the FWHCP 
agents 406 to determine which FWHCP agent 406 will operate. 

Assigned_Count_ofJ394_devices (39 16 ) - Assigned immediate 

25 value of the count of 1 394 devices in the network 300. The count is made as 
the 1394 interface goes though its self-ID cycles. The 1394 device discovery 
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agent 404 generates the value, which is saved in ROM space 403 for 
subsequent use by the IP and Ul configuration agents 406 and 408, 
respectively. 

IP_Address_Built_ln (3A 16 ) B Assigned Immediate Value. This address 
5 is assigned at manufacture time and built-in to the device. If this Built-in 
address cannot be used, an alternative address can be saved in the Assigned 
address space and the control bit set to indicate such. 

IP_Address_Assigned (3B 16 ) - Assigned Immediate Value. If identical 
IP addresses are detected, the IP address configuration agent FWHCP 406 
10 assigns this address to prevent collision. Further, the control bit is set to 
indicate such. 

IP_Address_Extension Leaf_for_attached_network (BC 16 ) - This 
directory entry is for the address offset to the data leaf for the IP address 
extension table, see Table 10. The data leaf contains IP addresses for devices 
15 on connected non-1394 networks (but also could be bridged 1394 networks). 
The table is included in communications devices of types (e.g., bridge) that 
connect through to foreign (non-1394) networks. The table can be expanded 
to include as many IP addresses as required. The address of the 
communications device itself should not be included in the table. 

20 



<Table 10> 



Leaf Length -1 (n) 16 


CRC-16 16 


IP Address 1 


(e.g., 32 bit) 




IP Address n 


(e.g., 32 bit) 



In regards to Control word for Discovery Control Bits, use of a ROM 
25 entry for the actual Discovery Control Bits word as defined herein works but 
is an example implementation. As ROM is not designed to be written 
efficiently (i.e., ROM areas have to be erased and writing them is slow relative 
to other hardware e.g. register). 
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Registers are provided in the 1394 hardware for data that must be 
written to frequently. In another version, a 1394 Register can be used for the 
•Discovery^controLbits 1 control word. Registers are in a space also 
addressable by other devices, whereby another device can look up in the ROM 
5 the address of the Register and then write to that Register. 

Referring Figure 9b, one or more devices include an IP address 
configuration agent (FWHCP) 406 (e.g., all Ul devices and Gateway devices 
and any other device that can be a Control initiator). The FWHCP configuration 
10 agent 406 accesses all devices' IP address values in data in the1394 ROM 402 
across the 1394 network 300. For synchronization commencement and 
completion of commencement of other applications (e.g., the Ul description 
generation), the FWHCP agent 406 also accesses the 'configuration, 
operating 1 control bits. 

15 

Referring to Figure 9c f devices capable of displaying user interfaces, 
and also some other devices (e.g., Gateway devices), can include the Ul 
description generation agent (UIDGA) 408 for generating the top-level Ul 
description 250 in e.g. HTML. Because as detailed above only one IP 

20 configuration agent 406 operates per network 300, not all devices need to 
include the IP configuration agent 406, though all devices can include an IP 
configuration agent 406. If a device has the operating IP Configuration Agent 
406 and is a User Interface Device then the IP configuration agent should 
operate before the Ul Description Generation agent. The Ul description 

25 generation agent (UIDGA) 408 utilizes information including control bits defined 
in the1394 ROM space 402 and other information (e.g., for determining which 
FWHCP operates is the Global Unique ID (GUID) of BusJnfo_Block of Table 
3) for determining which IP configuration agent 406 (if multiple in the network) 
operates, synchronizing commencement and for access to the in-use IP 

30 addresses. Any device may have and operate a UIDGA for making the 
HN_Directory page (top-level discovery page). After the IP addresses are 
configured UIDGA reads the addresses to make the HN_Directory page. In 
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each client device, when Ul description generation is complete, the GUI 
generation and run-time environment 410 (e.g., Web Browser 200 in FIG. 2) 
uses the Ul description HTML file 250 to access all devices 1 HTTP file space 
for icons, names and logos (lcon.HTM, Name. HTM and Logo. HTM are 
5 contained in pages 204, and 204) to generate the full top-level GUI 220 for 
display in that client device. Web Browser uses HTML file 250 to render the 
actual GUI graphics, in the process accessing files from the devices e.g. 
lcon.HTM, Name.HTM and Logo. HTM and in turn accessing any additional 
files these files reference e.g. ICON.GIF and LOGO.GIF. 

10 

<1394 Device Discovery Agent (1394DDA)> 

Referring to FIGS. 9a-c, 10 as discussed, each 1394WEB device in the 
network 300 can include the device discovery agent 404. The device discovery 
agent 404 enumerates the 1394 devices in 1394 address space connected to 

15 the 1394 bus, wherein the raw discovery is performed in 1394 hardware. The 
SelfJD and Physical Node Number Assignment and the steps leading to it is 
the basic discovery process performed by the interface hardware/firmware. All 
devices monitor the SelfJD cycles and make a note of the existence of 1394 
devices. This is a part of 1394 software for any 1394 device: (1) Reset -Bus 

20 reset propagates to all interfaces, on device power-up, device attachment and 
device detachment, (2) Tree Identification -Transforms a simple net topology 
into a tree, to establish a ROOT which is master for certain functions: Bus 
Cycle Master, Highest priority in arbitration for bus time, (3) Self Identification 
-Assigns Physical Node number (address) and also exchange speed 

25 capabilities with neighbors. Highest numbered node with both Contender Bit 
and Link-on Bit is Isochronous Resource Manager. 

The discovery agent 404 writes the final count value of the devices to 
the 1394 ROM space to communicate it to other agents. The device 
30 discovery agent 404 is the first software agent to execute after a 1394 reset 
cycle, and control bits (Discovery Control Bits 2 and 1, Configuration 
Operating: 1394DDA, and IP_Address) are used to delay other agents, 
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including the configuration agents 406 and 408, from execution until the 
discovery agent 404 has finished execution. 

In one embodiment, the1394DDA agent 404 in each device performs 
5 the steps 500, 502 including: (1) setting synchronization control bits 
(i.e.,'1394DDA in progress 1 and 'IP configuration in progress 1 bits) in the 
device's own 1394 ROM space 402 to indicate that the 1394DDA in progress 
and IP configuration is in progress (IP configuration will not be in progress if 
1394 DDA is executing) and that the values of 1394 device count and IP 

10 address are not valid, whereby said control bits inhibit other agents (e.g., 408) 
from operating prematurely; as such the 1394 DDA executes, then an elected 
FWHCP executes, and then (usually for Ul device) UIDGA executes; (2) 
counting the number of 1394 self-identity sequences after a 1394 Reset to 
discover the number of devices and effectively their local node addresses for 

15 use by the other agents 406, 408; (3) writing the device count value to the 
device's own 1394 ROM space 402; and (4) clearing (e.g., to false) the 
synchronization control bit for , 1394DDA in progress' in the device's own 1394 
ROM 402, wherein the IP configuration in progress 1 bit remains set and is 
cleared later by the operating FWHCP agent 406. 

20 

Alternative Architecture for Configuration with IP Address list in network 
communication (bridge) device is possible. For example, the IP address list of 
IP addresses of devices on a bridged (e.g., non-1394 network) can 
alternatively be examined at the IP configuration stage by the FWHCP agent 

25 406 rather than only at the UIDGA stage by the UIDGA agent 408. This allows 
the FWHCP agent 406 to detect and correct address collisions and therefore 
allow operation without having two separately defined address ranges, one for 
the 1394 network 300 and one for the non-1394 network 119. Correction of 
address collision can be accomplished by modifying the address of a colliding 

30 1 394 device as the bridged network IP address list cannot be modified by the 
aforementioned agents 406, 408 for the 1 394 network 300. Configuration is 
more reliable if the FWHCP agent 406 can check the addresses in the bridged 
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network 119 for collision prior to allowing the addresses used on the 1394 
network 300. 

<IP Address Configuration Agent (FWHCP Agent)> 

5 Referring to FIGS 9a-c, 10 the IP Address Configuration software agent 

(FWHCP) 406, operates to provide 'Fixed 1 IP address management and to 
detect and correct IP address clashes in the mass manufactured 1394 devices, 
All 1394WEB Ul devices include, and other devices can include, an FWHCP 
agent 406. Only one FWHCP agent 406 operates in the network however. 

10 The 1394DDA 404 agent is the first software agent to execute after a 1394 
reset cycle, and as aforementioned the1394DDA 404 agent sets the 
'1394DDA in progress 1 and 'IP configuration in progress' bits to delay the 
FWHCP agent 406 until the 1394DDA agent 404 has executed to completion. 

15 In one embodiment, the IP Address configuration agent 406 in a device 

performs steps including polling the 1394DDA configuration operation control 
bit (i.e., the "1394DDA in progress* bit) to determine if the 1394DDA 
configuration software agent 404 has executed to completion. If so, then the 
FWHCP agent 406 uses the count of devices determined by the 1394 DDA 

20 agent 404, and reads GUID's and Control Words from every device (step 504) 
to determine which device in the network 300 is selected to execute its 
FWHCP agent 406 (step 506). The selected device is one with an FWHCP 
agent 406 that finds it has the highest GUID (step 508). All other FWHCP 
agents 406 in other devices remain dormant (step 510). The operating 

25 FWHCP agent 406 reads the 'in-use' (active) IP address (determined by 
Discovery_control_bits BIT 0) from each local node (e.g. units present on the 
interface, host) and listed (step 512). In one version, the software agent 
makes a list for saving the IP addresses to an 'Array' as they are read (steps 
514-518). The list will be in memory (RAM or DRAM) under the control of the 

30 compiler and OS. In-use status is determined by a bit setting in the device, 
which indicates whether the built-in or assigned address is in-use. In Table 7 
the IP_address_assigned and IP_address_built_in are in the 1394Web Unit 
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Directory. 

The operating FWHCP agent 406 examines said list for collision among 
IP addresses listed therein (other collision detection and resolution methods 

5 can also be used) (steps 520-522). If a collision is detected, the FWHCP 
agent alters the colliding addresses by e.g. substituting the least significant 6 
bits of IP address for their 6 bit node address (step 524). Only the minimum 
number of alterations are performed to relieve the collision. If one of the 
colliding addresses is already an assigned address, then that address is 

10 altered in preference to the colliding built-in address by e.g. incrementing the 
6 bit substitute value and re-checking until the collision is resolved. The 
FWHCP agent 406 writes the altered value back to the device and the control 
bit (Discovery_ControLBits: Bit 0) is set to indicate that the assigned IP 
address is in-use, and the built-in default is no longer in-use (step 526). The 

15 process is repeated for each IP address (step 528). After the collision 
resolution process, the operating FWHCP agent 406 accesses each device 
in turn and sets the 'IP configuration in-progress' bits in each device to e.g. 
'false* to indicate that the indicated IP address is valid. 

20 <UI Description Generation Agent> 

In conventional WWW operation, users access the same top level page. 
Referring to FIGS. 4b, 7 and 9-11, according to an aspect of the present 
invention however, all Ul devices (e.g., devices capable of displaying user 
interfaces) include an Ul description generation agent (UIDGA) 408 to 

25 independently generate a top-level Ul page 220 for control of the devices on 
the local network (e.g., network 100, network 300, etc.) by users. In one 
example, a client device (e.g., PC) dynamically generates a locally saved 
default page 220 for user control of devices connected to the network 100. 
This allows each Ul device (e.g., DTV 102) to generate a different view 220 

30 of the home network e.g. with a larger more prominent icon for that Ul's 
devices displayed. As such, the user is readily made aware of which Ul 
device is 'right here 1 (in front of the user) or in the case of access external to 
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the home, no device is 'right here'. A device without a Ul can generate a Ul for 
another device but is unaware of type of device (e.g., Cable Modem generates 
Ul of HN devices for user external to the home). In this case the actual Ul 
device is unknown. Therefore no particular device is prominent in the GUI. 
5 Further, manufacturers of devices connected to the network 100 can provide 
their own GUI design 202, 204 in each device as desired. In addition later, 
improved Browser and Web technology designs need not be hampered by 
existing technology. 

10 Non-UI devices, particularly those devices performing a gateway 

function, can also include a Ul Description Generation agent 408 to generate 
top-level GUI descriptions 250, without including GUI Generation and Run- 
Time processes 410 (e.g., Web Browser 200) to generate and display GUIs 
220. With appropriate address use (e.g., using the RFC1918 private 

15 addresses on the local HN), this allows external WWW access to the 
1394WEB network devices.. External addresses are assigned 'rear IP 
addresses suitable for Internet use. Generally there is a unit (e.g., gateway 
type unit) with the UIDGA 408 which represents the home to the outside 
Internet. The gateway's UIDGA generates a different Ul description for the 

20 outside use (remote access case different from inside local device use), using 
the home's IP address with extended links to identify which home device local 
private IP address. 

Ul devices execute the following software processes to generate and 
25 display views 220 of the network 100/300: (1) 1394 Device Discovery Agent 
404 described above, (2) Ul Description Generation Agent (UIDGA) 408, and 
(3) GUI Generation and Run-Time (e.g., Web Browser 200) process 410. 
Referring to FIG. 11, in one embodiment, a UIDGA agent 408 in a device 
performs steps including polling the IP address configuration bits in the 
30 device's own 1394 ROM 402 to ensure completion of the FWHCP agent 406, 
prior to accessing any further IP information (step 600). Upon completion of 
FWHCP agent 406, using the count of devices generated by the 1394DDA 
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agent 404, the UIDGA agent 408 then accesses the control word in each 
device currently connected to the network, to determine the settings for the 
'configuration operating 1 false, and 'in-use* IP addresses bits (the UIDGA agent 
408 makes the top-level HTML page, HN_Directory page, 220 shown by e.g., 
5 in FIGS. 5-6). Thereafter, the UIDGA agent 408 reads the actual in-use IP 
address value, and builds a complete list of the IP addresses of the devices 
currently connected to the network 300. The IP address list includes 
information (e.g., Icon, Logo, Name, etc.) from every device, and is written in 
HTML by using the IP address of each device . Before it can include the 

10 addresses, the UIDGA 408 finds the address of each device by accessing each 
device and checking to see which address is in use by reading Table 9, 
Discovery_control_bit, control bit (Bit 0). Then UIDGA 408 reads Table 7 
Address either Builtjn or Assigned. For devices that communicate to bridged 
networks, as determined by the presence of the extension IP address list entry 

15 in that device's 1394 ROM 402, the UIDGA agent 408 reads the extension 
IP-addresses from the list (IP_Address_Extension_Leaf) to allow those devices 
to be included in the GUI 220. The entry BC (IP_Address_Extension_Leaf ) 
contains a reference link address that points to the actual data leaf. Devices 
on the attached bridged network are only included in the 

20 IP_Address_ExtensionJ_eaf list if they also support the 1394WEB type of 
service i.e. they have Web Server and Icon. HTM etc and Control pages 
(Index.htm). 

The UIDGA agent 408 reads the IP address list (step 602) and 
25 generates the top-level network Ul description 250 (FIG. 9c) in e.g. HTML (e.g., 
Appendix 1) using the IP address list (UIDGA outputs the HN_Directory, top- 
level network Ul page, HTML file) (step 604). The UIDGA agent 408 uses the 
IP Addresses in the hypertext links to each device for the icon.htm, 
name. htm and logo.htm files. UIDGA writes an HTML file including the 
30 references to each discovered device's HTML page i.e. ICON.HTM, 
NAME.HTM, LOGO.HTM (e.g., Appendix 2, 3, 4). The UIDGA agent 408 then 
uses HTML files to reference items including the icon and logo graphics files 
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and name data, rather than including the raw icon.gif or logo.gif and raw name 
text in the top level Ul description 250 (step 606). This allows said items to be 
changed by the corresponding device to reflect current status, customized by 
the manufacturer or configured by the user at the device, without causing any 
5 change in the top-level HTML Ul description 250 in the controlling Ul device. 
Though one graphic per device is shown in the example GUI pages 220 
(FIGS. 5-6), customization allows inclusion of more than one graphic file 
referenced by ICON.HTM or LOGO. HTM and more text in the NAME.HTM. 
In one embodiment, HTML frames are utilized to implement the Ul description 

10 250 as showing in examples further below. Use of frames stabilizes the 
appearance of the GUI 220 in the event of 'bad citizen' devices. For 
example a device presenting too many words or overly large text in its 'name' 
frame will only affect that device's GUI look (by having some of the words 
truncated and not displayed) and not adversely affect the appearance of the 

15 whole Top-level GUI 220 in the Ul device. The UIDGA 408 then invokes the 
GUI generation process 410 (e.g., browser) in a client device to generate and 
display a user interface (step 608). 

<GUI Generation and Run-Time Processes> 

20 The GUI generation process 410 (e.g., Web Browser .200) utilizes the 

Ul description 250 in e.g. HTML to generate GUI pages 220 on Ul devices. 
In one example, to provide keyboard-less operation for consumer electronics 
devices (e.g., DTV) the Browser 200 at start-up defaults to reading and 
rendering a locally generated 'top-level-devices.html' description 250 to 

25 generate the network top-level control GUI 220. Locally as used here means 
in the same device (a Ul device having a UIDGA that generates the device's 
own HN Directory (top-level) GUI of the network devices). HN Directory, Top 
level Network Ul and Discovery page are the same. For personal computers 
(PC) with keyboard this need not be the default: For CE devices, launch of 

30 the Browser 200 is delayed until after completion of the UIDGA default page 
250 generation by the UIDGA agent 408. In the event that UIDGA agent 408 
cannot complete its tasks, then the Browser 200 displays an alternative Ul 
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page 220 showing a network configuration error occurred (e.g., "Unable to 
generate the HN ^Directory Page because of xxxxxx. Try disconnecting device 
xxxxxxx. Network configuration error number xxxxxx occurred. Contact service 
Tel service xxx-xxx-xxxx or Web service http.7/www.service.com. M ) 

5 

To generate the GUI 220, the Browser 200 fetches the 'icon.htm', 
'name.htm' and 'logo.htm' files from device information 202, 204 in each 
referenced device (i.e., in the Ul description, where for example ICON. HTM is 
in the HN ^Directory Page HTML file) as defined by the HTML Ul description 

10 250. The contents of these pages 202, 204 (e.g. the icon graphic) need not be 
static and can be altered dynamically to reflect device status change, or after 
user customization. In order to display the most current top-level page 220, the 
Browser 200 does not cache the 'icon.htm', 'name.htm' and 'logo.htm' files. 
In another version, a check is always made first to determine if the device has 

15 made any changes to the HTML files 202, 204 it holds. HTTP "Conditional get" 
is used for checking the status of controlled device. Depending on the status 
code returned, the Browser 200 will either read from its cache or fetch a fresh 
or updated copy the HTML file 202, 204 from the devices. The HWW GUI 
display is not affected unless there is any change of the status of the controlled 

20 device. 

The browser 200 does not attempt to display the top-level HN directory 
until it has been completely generated. If the HTML 250 is not generated within 
some reasonable amount of time, the browser displays an alternate page. If 
25 a network configuration error is the source of the problem, the alternate page 
might provide some technical support or user diagnostic assistance. 

Whenever the user returns to the top-level HN directory or causes it to 
be refreshed, the browser 200 redisplays the page 220 in its entirety. This is 
30 necessary because the HTML 250 that underlies the top-level HN directory 
may have been regenerated if a device has been added to or removed from 
the network 100. It is also possible for device icons to be updated to reflect 
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changes in their device's operating state. As such, browsers implemented by 
EIA-775.1 devices use HTTP "conditional get" requests to determine whether 
or not fresh copies of web pages or graphics are retrieved from the server. 

5 In this aspect, the present invention provides a User Interface 

description where user discovery of devices is thus made entirely with 
references (i.e. in the abstract), where the references are 'containers 1 for the 
discovery information (e.g., text and/or graphics) of each device and resident 
on each device. Each •container 1 includes actual textual information and/or 

10 references to one or more graphics formatted information files where each file 
may include one or more images and/or text. Use of the reference 'containers' 
allows each device to choose its preferred Ul content or graphics format or 
alter its Ul content to be displayed (by changing the text or graphic information 
referred to) without need to have the Ul description page altered in any way. 

15 Therefore, communication of changes with the generating agent software of 
the Discovery Ul description is not required. In one version, devices reference 
their e.g. ICON and LOGO graphics files indirectly using HTML files enabled 
by creating the network Top-level description using HTML frames. Similarly the 
device name that is displayed under the icon is represented by NAME HTML 

20 file. HTML files are used to reference e.g. the icon and logo graphics files and 
name data rather than include the raw icon.gif or logo.gif and raw name text. 
This allows the item to be changed to reflect current status, customized by the. 
manufacturer or user configured at the device without causing any change in 
the top-level HTML description. This level of abstraction allows the Top-level 

25 Ul description to be always the same regardless of the graphics ICON and 
LOGO file names and types and NAME text to be displayed. Also the device 
may use different, multiple or dynamically change the graphics files and text 
displayed in the Top-level GUI without the change needing to be : 
communicated to the UIDGA. The change is automatically included whenever * 

30 the GUI is redisplayed. Use of frames also stabilizes the GUI display in the 
event of bad citizen devices using non-displayable graphics or text as the error 
is confined to the particular frame and doesn't affect the whole GUI. 
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The change is automatically included whenever the GUI is redisplayed. 

In one example, network devices top-level Ul description is generated 
independently by any network device and certainly by devices capable of 
5 displaying Ul (Ul device). Generating a user interface in each device rather 
than generating a centrally Ul, allows a device to show its own device icon/text 
preferentially in the GUI. In addition each GUI is manufacturer customizable, 
user configurable and also more reliable because it does not depend on 
another device e.g. a single central server. This is demonstrated with the 1394 
10 scheme above. Multiple Ul generation is enabled because all device IP 
addresses are accessible via the 1394 interface. Ul devices (with Browser) 
include UIDGA agent to generate their own top-level GU! description after a 
1 394 reset cycle when a device attached or power-up. 

15 All Ul devices independently generate a top-level Ul page for control for 

the local network. This is different from the conventional WWW operation 
wherein users access the same top level page. According to one version the 
present invention, the client device (e.g., PC) dynamically generates a locally 
saved default page file for any purpose, allowing each Ul device (e.g., DTV) 

20 to generate a different view of the home network e.g. with a larger more 
prominent icon for its own display. Further manufacturers have scope to 
make their own GUI design better then another. In addition later, improved 
Browser and Web technology designs need not be hampered by earlier 
technology. 

25 

Referring to Appendices 1-4, illustrative examples for the following are 
provided: (1) Top-Level Page description 250 (Appendix 1); (2) 
Background.htm (Appendix 2); (3) lcon.htm (Appendix 4); and (4) Name.htm 
(Appendix4). 

30 

<Linked External Web Server/service> 

According to another aspect of the present invention, network 
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configuration and user interface (Ul) description generation for the home 
network top-level page Graphical User Interface (GUI) are performed to 
provide external services (e.g. web services) from an external network (e.g., 
Portal) as well as from home network devices 11. In one embodiment, the 
5 external network includes interconnected devices providing services (e.g., 
servers comprising one or more computing systems executing software for 
providing services). As such, in one example, manufacturer's Portal (external 
Web Server) services from an external network 702 (FIG. 7) are included in 
home network top-level user interface description 250. 

10 

In one implementation, internet gateway address of a gateway 700 is 
defined in an address space visible to all 1394 devices in the home network 
300. Thereafter, for at least one device 1 1 (e.g., client device 12 such as DTV 
102) in the home network 300, if a gateway 700 is detected by e.g. the 

15 discovery agent 404, then the Ul description generator agent (UIDGA) 408 of 
that device 1 1 can include external IP addresses in the home network top-level 
Ul description (TLNUID) 250 (as well as Home Network device addresses 
described above) of that device 11. Alternatively, each device 11 can 
discover the gateway device 700 by communicating and obtaining information, 

20 for example, from another device (such as DTV 103, or cable modem) to get 
the gateway IP address, or the device 11 can communicate with the gateway 
device (use gateway device's internal IP address) to get the public/external IP 
address of gateway device. External services from an external network 702 
of interconnected devices 704, can be accessed from one or more IP 

25 addresses (or Portal) known to the UIDGA 408 when the top level GUI 220 is 
generated or refreshed in that device 11. In a version, the external home portal 
IP address is preprogrammed into the UIDGA 408, whereby the UIDGA 408 
need not obtain the external address through the gateway device. In one 
example, each device 704 includes one or more computing/computer systems 

30 executing software for providing services (web services), wherein the devices 
704 are interconnected via routers and communication links (e.g., Internet). 
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FIG. 12 illustrates a pictorial outline of the TLNUID 250 showing actual 
HTML file name reference and address of a logoicon htm file 71 OA (residing 
in a server 704 in the external network 702), and an actual HTML file name 
reference and address of a logoname htm file 71 2A (residing in a server 704 
5 in the external network 702). FIG. 13 illustrates the Browser rendered GUI 220 
based on the TLNUID 250. Content of logoicon and name items 710B, 712B 
in FIG. 13 for services from the Portal are refreshed whenever the top-level 
GUI page 220 in that device 1 1 is updated. Further, Portal or content page 
hits are generated whenever the network top-level GUI 220 in that device 1 1 
10 is refreshed (and preferably not when top-level description 250 is generated). 

In one example implementation, the manufacturer of a device 11 (e.g., 
DTV 102) can choose to program the UIDGA 408 in that device 1 1 to include 
externally provided service logos icons in the home network top-level GUI 220 

15 of the device 1 1 . Such functionality is built-in to the GUI description generator 
agent (UIDGA) 408. The service logo page 708B, logo graphics 71 0B and 
text 71 2B, address a web server 704 external to the home network. The 
logos 71 0B can represent, and be actively hyper-linked to, services, 
information, media etc. provided by devices 704 in the external network 702 

20 via the gateway 700. Further, device icon spaces 708B unused in the Top- 
level Home Network device's page 220 can be filled with service logos or icons 
71 0B and names 71 2B from an external Web site provided by a server device 
704. In one example, there can be as many as 12 unused icon spaces for a 
minimum home network including one device. Referring to the example 

25 TLNUID 250 and the GUI 220 in FIGS. 12-13, there are a minimum of 12 
service logo-graphic 71 0B, logo-name 71 2B sets for the GUI 220. The logo 
file names 710A can have a number from 1 to 12 e.g. logoicon1.htm through 
logoicon12.htm, and are accessed in order from lower to higher numbers. 
Similarly , the name file names 71 2A can have a number from 1 to 12 e.g. 

30 logoname1.htm through logoname12.htm, and are accessed in order from 
lower to higher numbers. The following example specification is similar to that 
for device icon described above. 
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A logo icon and name file, 710A, 712A, respectively, per service 
represent the service graphically in the Top-level Home Network devices page 
250 shown in FIG. 12, and in the corresponding GUI 220 shown in FIG. 13. 

5 A graphic file 71 OB having a name is referenced in a corresponding HTML 
page 71 OA. The graphic 710B is hyper-linked to the service top-level page 
71 OA. An example graphic specification can include: Graphic file type of GIF, 
JPG or PNG (any name), and Logo icon graphic maximum size of 
70(V)x1 30(H) pixels. An HTML page 250 references the graphic file 71 OA, 

10 with the first accessed file 71 OA representing the primary service logo graphics 
710B named logoicon1.htm 710A. Subsequent logos can use files with 
incrementing number. It is possible to include more than one graphic reference 
in logoiconl .htm. In this case the service image is hyper-linked to the service 
home page and the second image (e.g., logoincon1_1.htm) can be hyper- 

1 5 linked to a different location. 

Further, a minimum of one logo name file 712A includes text 712B to 
augment the logo graphic (logoicon.htm) in the Top-level Home Network 
devices page 250. The text 71 2B includes a few words to go with the service 

20 logo icon graphic relevant to the service. Name (e.g., "VCR livingroom" as 
name of a VCR in the livingroom) can include text in an HTML page called 
logoname1.htm. Subsequent logos can use files.. with incrementing number. 
Preferably, only the file name is standardized and not the text. The text can 
also be hyper-linked. An example specification can include: Text unspecified, 

25 without font restriction. As an example with Font size 1 0, two lines of text can 
be displayed under the logo icon. 

An example discovery process supported by every home device 1 1 
supporting the EIA-1394WEB standard is now described. Because user 
30 control of devices indirectly via a Graphical User Interface (GUI) 220 is 
s important for keyboard-less operation of devices 1 1 anywhere on the Home 
Network 300, and for services provided by devices 704 outside the home 
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network 300, one function of the discovery process is to bootstrap Internet 
Protocol and bootstrap Web based control. The former includes device 
discovery 404 and IP address configuration 406 and the latter includes 
generation of a top-level network user interface description (TLNUID) 250 by 

5 the UIDGA 408 for the Browser default page that it renders to generate the top- 
level user control GUI 220. The Ul description (GUI source description) 250 
in FIG. 12 includes graphical icon reference 706A and a textual name 
reference 707A representing each device 11 in the home network 300, 
corresponding to graphic 706B and name 707B, respectively, in FIG. 13. The 

10 Ul description (GUI source description) 250 further includes the graphical icon 
reference 71 OA and a textual name reference 71 2A representing each 
external service from the externa! network 702, corresponding to graphic 71 0B 
and name 71 2B, respectively, in FIG. 13. The Browser collects a graphic 
image(s) and name from each device and service, as renders the GUI 220 as 

15 shown by example in FIG. 13. 

Each 1394WEB Ul device 11 (e.g., client device 12 such as HDTV 102) 
separately generates the network top-level Ul description 250, allowing the 
device to give priority to itself in the displayed GUI. In FIGS. 12-13 a host 
20 HDTV 102 that generates and presents the top-level GUI 220 assumes priority 
and uses a 4x large size icon. Different manufacturers can develop their 
own GUIs and can develop different ones for each device model wherein e.g. 
a hand-held Web controller generates a much simpler GUI than a HDTV. 

25 For a home network connected 300 to an external network 702 such 

as the World Wide Web (e.g., via the internet), device (e.g., TV) manufacturers 
can design a device UIDGA 408 to include logo or icon pages (e.g., 
logoicon1.htm and logoname1.htm) hyper-linked from the manufacturer's Web 
site in a server 704 in the external network 702. In FIGS. 12-13 the bottom row 

30 includes e-commerce logos 712B from an example external Web Server or 
Home Portal, address 209.157.0.2, .operated by a TV manufacturer. The 
primary logo item shown on the left hand side is an example logo graphic 71 0B 
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and name 712B from the manufacturers Web site (e.g. domain name 
homewideweb.net , address 209.157.0.2). In that example, the YAHOO (TM) 
icon embedded in the second logo page (e.g., logoicon2.htm and 
logoname2.htm) is obtained from the TV manufacturer's Web site or Home 
5 Portal and not directly from the YAHOO web site. The TV manufacturer may 
allow customization of the GUI 220 wherein service icons and logos are 
obtained from a Web Server or Portal outside of the manufacturer's control. 

In one example, the discovery process reads information from the 1394 

10 address space data storage (e.g., configuration ROM structure), as defined in 
clause 8 of ISO/IEC 13213. Although called 'ROM 1 it is assumed that the 
address space is wriie-able to allow user configuration and modification of user 
relevant stored values. The discovery process substantially comprises the 
steps described hereinabove, with the following additional or different functions 

15 for external Web link. Each device 1 1 keeps an extension data leaf in 1394 
ROM space for IP addresses of devices 704 on the non-1394 network 702 
(e.g., FIGS. 7, 14), and additionally an immediate data value for the Internet 
Gateway address as information for all the 1394 devices 11. Any 1394 device 
1 1 can discover the Gateway address. The Internet Gateway device 700 or a 

20 device (e.g., DTV 103) communicating with non-1394 network 702 supporting 
the gateway device 700 includes the IP address of the gateway in ROM space 
(1212R) as defined. One or more devices 1 1 (e.g., DTV 102) can make their 
own icon more prominent (bigger), give the entire GUI 220 a different look and 
include logos and icons 71 0B from the external portal (e.g. manufacturer or 

25 other website provided by one or more devices 704 in the external network 
702). Logos 71 0B from an external Web site(s) or Portal can be included in 
the top-level GUI 220 under the control of e.g. the TV manufacturer provided 
DTV Ul description generator 408, for various (e.g., business) purposes. 
One or more of the devices 11 can further include IP address of Internet 

30 Gateway (if gateway or bridge device if present), relevant to the discovery IP 
address for 1394WEB in the 1394 configuration ROM. 
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Referring to FIG. 15, during an example operation scenario of a UIDGA 
408 in a device 1 1 (step 800), if a gateway IP address is encountered during 
the search of 1394 ROM space (step 802), it is noted to allow inclusion of 
externally accessed logos 710A, 712A in the Top-Level Network Ul Description 

5 (TLNUID) 250. Then the UIDGA 408 reads the IP address list of devices in the 
home network 300 (step 804) discovered by the DDA 404, the UIDGA 408 
obtains the home portal IP address (step 806) and generates the TLNUID 250 
in HTML using the IP address list, including links to external services provided 
by the network 702 (step 808). As shown by example in FIG. 12, the 

10 representative format of the TLNUID 250 comprises a matrix of icon graphics 
and underlying text representing the functions of the devices or services to the 
user. The Home Network devices 11 are given priority in the valuable 
TLNUID device-icon space. According to the TLNUID description 250, for 
home network devices 1 1 , the icon. htm 706A page contents 706B are placed 

15 in the large space and, and the name.htm 707A content 707B in the smaller 
of the vertically adjacent frames for each device. IP addresses of devices 1 1 
connected to the home network 300 are used in the hypertext links to each 
device for their icon.htm and name.htm files (shown by examples further 
below) (step 810). 

20 

Further, during operation of the UIDGA 408 in a device 11, if a Gateway 
700 is detected (e.g.; by the DDA 404), any device-icon GUI spaces remaining 
as a result of e.g. having a small network, using multiple levels (e.g., moving 
some device icons to a second level page), etc. can be used for externally 

25 accessed logo-items 708A, at the discretion of the UIDGA 408. In the 
TLNUID 250, the external logo-items 708A (e.g., each a logo graphic file 
71 OA and associated name 71 0B) are obtained from, for example, a 
manufacturer's Web server (e.g. home portal) at a fixed external IP address 
in the external network 702 under the control of the manufacturers UIDGA 408. 

30 The logo-items 708A include predefined page names 71 OA, 71 2A, and are 
accessed in number order (e.g., logoicon1.htm, logoname1.htm first and then 
logoicon2.htm, logoname2.htm and so on) (step 812). The manufacturer (or 
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operator of the Web server) can insert the appropriate graphics and/or text with 
hyper-links inside said pages 71 OA, 71 2A. As such, in this example, 
logoicon1.htm 71 OA and Iogoname1.htm 71 2A, get included in the TLNUID 250 
more often, and higher numbers are included least. The TLNUID 250 is then 
5 utilized by the browser 410 to generate and display the GUI 220 (step 814). 

In example versions of the TLNUID 250, HTML files are used to 
indirectly reference the actual graphics files 71 0B and name data 712B rather 
than directly including the raw graphic file name/type and name text. This 

10 provides a layer of abstraction that allows the item (e.g., actual graphics files 
71 0B and name data 71 2B) to be changed on the device side to reflect current 
status, customized by the manufacturer or user configured at the device 
without causing any change to the TLNUID HTML 250. Though intended for 
one graphic, more than one graphic file and text can be referenced by icon. htm 

15 or logoiconX.htm and graphics and text referenced in name.htm and 
logonameX.htm. 

In example embodiments, HTML frames are used to implement the Ul 
description 250. Use of frames stabilizes the GUI 220 appearance in the event 

20 of 'bad citizen' devices. For example a device presenting to<? many words or 
over large text in its 'name' frame will only affect that device's GUI look (by 
having some of the words truncated and not displayed) and not adversely 
affect the appearance of the whole Top-level GUI. As the Top-level 
description 250 is generated independently by Ul capable devices (e.g. client 

25 devices 12 such as DTV 102), the exact design need not be standardized. 
The icon and logo graphics and name maximum sizes are standardized to 
facilitate design of the GUI matrix. 

The top-level GUI 220 including many devices 11 and services 708B 
30 can be designed according to a prior user access frequency. Devices 1 1 or 
services 708B with higher access frequency can be given prominent display 
on the top-level GUI 220 or higher level GUI pages for ease of use. A 
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software agent running with the Browser can be utilized to provide such a 
function. The software agent monitors the user access to each device 11 or 
service 708B, counts the accesses and saves the number of accesses per 
device/service IP address to a data file in a place that is accessible by the User 
5 Interface description generator agent UIDGA 408. The data file comprises e.g. 
a simple list of IP addresses and counts. If a file and count already exists for 
a particular IP address, the new count is added to the existing value. 

In one version, the UIDGA 408 is preprogrammed with one or more IP 

10 addresses in the external network 702 to access one or more external web 
sites, wherein a portal comprises one or more fixed web sites. The DDA 404 
discovers the devices 11 in the home network 300, while the UIDGA 408 is 
responsible to generate the top level TLNUID 250. The gateway 700 is used 
to route the data to external networks 702. Every time there is a request to 

15 access an outside network 702, for example, external portal on an internet web 
site, the request is routed by the gateway 700 to the outside network 702 
(specified by network communication). The UIDGA 408 uses the 
preprogrammed external portal IP address to generate the TLNUID 250 for the 
top-level GUI 220 including e.g. an icon graphic representation 71 0B for the 

20 external services, then the GUI 200 is presented to the user. When a user 
accesses the external link/network by clicking on an icon 71 0B in the GUI 220 
representing a device/service in the outside network 702, the request is sent 
out of home network 300 to the external network 702 through the gateway 700. 
The Browser 410 is used to display the top level GUI 220, just the same as 

25 the case where no external links are used. In one version, the UIDGA 408 
only includes a 'base' external service portal IP address (e.g. a device 
manufacturer's web site or portal address), without the need to know the 
external link IP addresses of other external services such as yahoo.com, 
amazon.com, which are stored in the base portal web site and then provided 

30 to the GUI 220, in files such as logoiconl .htm, described by example below. 



Though in the above description an example implementation describes 
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manufacturers as placing portal information in the devices, others are possible. 
Further, though the external web site is described as a device manufacturer's 
web site, any other external web site can also be utilized. 

5 Referring to Appendices 5-12, illustrative examples for the following htm 

files for generating the TLNUID and GUI in FIGS. 12-13 are provided: 
Appendix 5 - Top-Level Page Example TLNUID (index.htm) 
Appendix 6 - background.htm example 
Appendix 7 - icon. htm example 
10 Appendix 8 - Example name. htm 

Appendix 9 - Example logoicon1.htm 
Appendix 10 - Example logoname1.htm 
Appendix 11 - Example logoicon2.htm 
Appendix 12 - Example logoname2.htm 

15 

The Top-Level Page Example TLNUID (index.htm) 250 implements the 
TLNUID 250 and GUI 220 shown in FIGS. 12-13. Eight Home Network 
devices 1 1 are shown represented in the top 75% area of the GUI 200. The 
lower 25% of area, i.e. the bottom row, shows logo pages 708B from the 

20 manufacturer's chosen external Web Server or Portal of a fixed IP address. 
The TLNUID 250 is generated using frames. Hyper-links to the local device 
11 graphics and name pages all use their 10.X.X.X local addresses. Hyper- 
links for the externally provided logo graphics and names pages 71 OA, 71 2A 
use the single external IP address (e.g., 209.157.0.2) provided by the 

25 manufacturer. As such control of the logo display 708B, and services offered, 
is provided by the TV or device manufacturer i.e. the provider of the TLNUID 
generator agent 408 in each of one or more devices 1 1 . The "DVD 1 " device 
1 1 icon frame includes two graphics from the device 1 1 . This does not affect 
the TLNUID 250, however when the Browser 410 renders the GUI 220, at least 

30 one icon.htm 706A can reference two graphics files, one (device graphic 721 ) 
hyper-linked to the device 11 top level control page and the other (logo 720) 
hyper-linked to the manufacturer Web Server for customer support, service, 
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help, etc. 

The icon.htm 706A example description page is accessed from the 
device 1 1 when the Web Browser 410 renders the top-level GUI 220 and used 
5 to fill an icon space. The browser 410 reads this page 706A and makes further 
accesses to the device 1 1 to fetch the actual graphic icon.gif 706B for display. 
The icon.htm 706A description shows that the device default control page 
index.htm is the hyper-link attached to the graphics causing the page to be 
fetched when invoked. When invoked the device home control page is 
10 displayed in a new Browser window. 

The name.htm 707A example description page is accessed from the 
device 1 1 by the Web Browser 410 when it renders the top-level GUI 220. The 
text 707B contained in name.htm 707A is placed directly under the icon 706B 
15 and provides ability, through facilities provided to the user through the device 
control pages, to apply user-customized text under the icon. 

The logoincon1.htm 71 OA example description page is kept on an 
external Web Server 704 operated by the hardware manufacturer (e.g., 

20 homewideweb.com). The page 71 OA can include logo graphics to enable 
access to a service. A hyper-link in the TLNUID 250 provides access to the 
external Web Server 704 supporting that particular service. In this example 
case the address actually corresponds to the same Web Server or the Portal 
supporting the logo pages themselves -domain name , homewideweb.com\ 

25 The logoiconl .htm 71 OA example description page is accessed in the Web 
Server 704 by the Web Browser 410 in the device 11 to render the top-level 
GUI 220. Similarly the file logonamel ;htm 71 2A in the server 704 is accessed 
by the browser 410, and the text 712B in logoname1.htm 712A is placed 
directly under the logo graphic 71 0B and can be used to augment the graphic 

30 in describing the service. 

As such there is a first hyper-link between the top level page 250 in the 
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device 11 and the logoincon1.htm file 710A in a server 704, and there is a 
second hyper-link between the logoicon1.htm file 71 OA and the actual logo 
graphic 71 OB. The UIDGA 408 places the first hyper-link to the logoinconl .htm 
file 710A in the top level page 250 for use by the browser 410 to access the 
5 logoinconl .htm file 71 OA kept in the server 704, and the browser 41 0 utilizes 
the second hyper-link in the logoincon1.htm file 710A to access the actual logo 
71 OB (e.g., home wide web, Yahoo (TM), Amazon (TM), etc.) to display in the 
GUI 220 in the device 11. 

10 In one example, the logoicon1.htm file 71 OA in the home portal (e.g., 

server 704) includes a hypertext link to the corresponding Home Wide Web 
icon graphics file 71 0B in the home portal, and the logoiconr.htm file 71 OA 
in the home portal (e.g., server 704) includes a hypertext link to Yahoo(TM) IP 
address for the corresponding Yahoo icon graphics file 71 0B. 

15 

The logoicon2.htm hyper-link is kept on an external Web Server 704 
operated by the hardware manufacturer, and is for an external Web Server 
supporting a particular service. In this example, the logoicon2.htm includes 
hyper-link to the IP address of the YAHOO(TM) domain 204.71.200.75 to 

20 reference directly to the YAHOO Web site. DNS (providing name address 
look-up and allowing use of the name) is not required as the user interacts with 
the Yahoo graphic which does not change, and its hyper-link in the 
logoicon2.htm page can easily be changed to reflect any new address any time 
the GUI 220 is redisplayed/refreshed. In one example, the actual GUI 220 

25 is generated from the HTML description 250 at start-up or re-start after a 
device 1 1 has been added to the network 300, and at a refresh. 

For the example linked external web server implementation, example 
Table 11 below is used instead of the unit directory table 7 above, showing 
30 the EIA-775 Unit Directory, whereby the following EIA-1394WEB specific 
information should appear in the EIA-1394WEB Unit Directory. 
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<Table11> 



Directory length 


CRC 


12< e 


Unit ^nprifiratinn in fFIA = nfl^flfift ^ 


13 


1 Init cnfhx/aro uDrcinn t H1 H1 Hfi \ 

unii_5Qiiware_veroiQn \\j iu iuu^ 






38 16 


Discovery_control_bits 


39 16 


Assigned_Count_oM 394_devices 


3A 16 


IP_Address_Built_in 


3B 16 


IP_Address_Assigned 


BC 16 


I P_Address_Extension Leaf_for_attached_network 


BD 16 


I P_Add ress J nternet_Gateways J_eaf 






"16 


«possibiy other fields» 



5 The Unit_specification_ID specifies the identity of the organization 

responsible for the architectural interface of the unit and the specification. In 
this case the directory and identity value=005068 16 .refers to the EIA as the 
responsible body and the EIA-1394WEB control architecture specification. 

10 A data leaf contains a table of gateway IP addresses to allow for more 

than one gateway address. It is intended for communications devices. This 
may be the same device or in another device on a bridged network (e.g., FIG. 
7 including the 1394 and non-1394 device). An 
IP_Address_lnternet_GatewaysJ.eaf (BD 16 ) directory entry is included for the 

15 address offset to the data leaf for the IP_Address_lnternet_Gateways_Leaf 
as shown in example table 12 below. Gateway addresses are used by host 
client software to direct external addresses to the Internet. Filtering for external 
addresses is by assumed sub-net mask 255.0.0.0 for the 10.X.X.X private 
network. 

20 
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<Table12> 



Leaf Length -1 (n) 16 


CRC-16 16 


IP Address 


1 (32 bit) 




IP Address 


n (32 bit) 



Further, in addition to the requirement that the Bus_lnfo_Block, 
5 Root_Directory, and Unit Directories be present, it is also required that a Model 
Directory be present (e.g., Table 13 below). The following fields (defined in 
IEEE1212r are required of all nodes supporting the EIA-775 specification: 
ModelJD, Textual descriptor for ModelJD. The Model-Directory portion of the 
ROM is referenced by the ModeLDirectory offset field in the Root Directory. 

10 

<Table 13> 



ModeLDirectory 



directory length 


CRC 


17 16 


ModelJD 


81 16 


Device_name_textual_descriptor offset 




«possibly other fields» 







15 As used herein, in one example, services provided by the network 702, 

or one or more of the devices 704, includes e.g. services, information, data, 
transactions, e-commerce, data transfer, news, information, manufacturer web 
sites, etc. that can be provided by the Internet and Word Wide Web. Other 
services provided by other external networks are contemplated by the present 

20 invention. 

<Regional Service Support> 

In another aspect, the present invention provides Regional Service 
Support in home Network Top-level Home Page, and Device Manufacturer's 
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Portal (e.g., External Web Server) provide services for networks (e.g. home 
networks) that include externally provided logos or icons in their home network 
top-level GUI (described above). The regional service support is based on 
the linked external web server, wherein the functionality is also built into the 
5 GUI description generator agent (UIDGA). Regional service provides 
advantageous features for e.g. home networks because typically information 
and services are localized by region. For example, such information can 
comprise local news, weather information, etc., and services can comprise 
cable service, Internet service, local TV program, etc.. As such, 
10 manufacturers that include externally provided logos or icons in their home 
network top-level GUI can further include regional service support based on 
the linked external web server. 

In one implementation, redirection identification code (RIC), for example 
15 regional identification code, is used for User Interface devices 1 1 in the home 
networks to identify their geographical location using e.g. one-time user 
configuration or automatic configuration. For example, area code, IP address 
or Zip code can be used as RIC. The choice of different RICs does not affect 
the regional service support. 

20 

Referring to FIGS. 17 and 19, in one embodiment, the present invention 
provides regional service support in home network top-level home page 
generating process and device manufacturers portal services using Zip code. 
Regional service is supported in the top-level homepage generating process 

25 UIDGA, wherein RIC is obtained (step 820) and embedded into HTTP links to 
external web servers by the top-level homepage generating process UIDGA 
in the top level page 250 (e.g., FIG. 16) (step 822). The browser 410 displays 
the GUI 220 based on the top level page 250 (step 824). Manufacture's portal 
services 908 supports regional service, wherein regional service redirection by 

30 said manufacturer portal based on RIC is included in HTTP requests from 
home devices 1 1 . When a user clicks a cable service external link in the top- 
level home page 250 in a User Interface (Ul) device 1 1 (step 826), the device 
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1 1 uses the hyper-link to the portal 908 to send a an HTTP request with RIC 
to the portal 908 (step 828). After looking up a RIC/local service provider 
database 900, redirection programs 904 in the manufacturer portal 908 
redirects the HTTP request to a destination portal 910 in external network 702 

5 based on the RIC (steps 830, 832), wherein in one example, relative to the 
portal 908, the destination portal 910 is local to the device 11 Then, the 
browser 410 displays the web page of the local cable sen/ice provider for the 
user's specific location (region). Manufacture's portal services supports 
regional service, wherein regional service redirection by said manufacturer 

10 portal based on RIC is included in HTTP requests from home devices 11. 
The external network can comprise multiple portals 908 and multiple portals 
910. 



Referring to FIG. 18 and 20, the RIC of a device 11 is obtained when 
15 the device 1 1 dials in home portal 908, the portal 908 obtains phone area code 
(for example, by caller ID) (step 840). The portal 908 can map area code to 
another RIC, for example zip code, and the software agent 902 in the device 
11 receives the RIC. The additional steps 842-852 in FIG. 20 are similar to 
steps 822-832 in FIG. 19, and are not repeated. 

20 

In one example scenario, when a user with a user interface device 11, 
.. such as a Samsung (TM) HDTV 102 in Los Angeles, clicks on the external link 
icon for e.g. cable services, an HTTP request/inquiry is sent to the Samsung 
Home Network portal with the RIC in the URL from that HDTV 102, wherein 

25 said Samsung portal redirects the inquiry to e.g. a cable service provider in Los 
Angeles based on that RIC. The Samsung portal redirects the inquiry to a 
cable service local to that HDTV 102 based on the RIC in the inquiry. In this 
example process, the Samsung portal receives the RIC from the HTTP get 
message or post message. As such, in this example, an HDTV 102 in a 

30 network 300 in New York has a different RIC than the HDTV 102 in Los 
Angeles in another network 300, wherein each RIC indicates geographical area 
of a HDTV. The portal 908 redirects requests for service from each HDTV in 
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a different geographical area to a portal 910 local to the requesting HDTV 
based on the RIC of that HDTV (FIG. 21). 

<Regional Identification Code> 
5 As described, a regional identification code (RIC) is utilized for Ul 

devices 11 to identify geographical location of such devices 11 in different 
networks. The RIC can comprise e.g. zip code (5 digit or 9 digit), phone 
area code, IP address of the device or the home network, IP address of the 
service provider, or any other identification information. The RIC can also 

10 comprise a combination of the above examples. For example, using zip code 
or phone area code, the geographical location of the Ul device and the local 
service provider in the geographical area can be determined. Because each 
local Internet Service Provider (ISP) is typically assigned fixed IP addresses 
or IP address block, and they further assign certain IP addresses or blocks to 

15 a regional area, this allows determination of the ISP and region information 
from an IP address. The portal can use this regional information to further 
provide the web page of the local service provider (e.g., cable or other 
services). In one version, e.g. a 5-digit Zip code is used as RIC, while in 
another version e.g. 9-digit Zip code is used for detailed geographical 

20 information. The choice of 5-digit or 9-digit Zip code does not affect the 
regional service support. The choice between Zip code, area code, IP 
address or other possible codes does not affect the regional service support 
as describe herein. 

25 <Portal Service with Regional Support> 

For portal service with regional support, in one example a home device 
manufacture's portal services supports regional service (i.e., regional redirect 
service) based on RIC enclosed in the HTTP request from the home devices 
11. The portal with regional support redirects the HTTP request to a URL 

30 local to the request based on RIC. 

After the UIDGA builds the top level directory 250 in FIG. 16 (the 
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directory 250 including portal address, RIC and hyperlinks for obtaining name 
and logo information from the portal for external service), when the browser 
410 executes, the portal sends HTML files (logoicon1.html 71 OA, 
logoname1.html 712A, etc.) for icon and name representing external services 

5 to the device 1 1 for display on the GUI 220. These html files 71 OA, 71 2A can 
be from the same web site or different web sites (e.g., general web site such 
as the portal or service provider web site). Referring to FIGS. 17-18, 
thereafter, when a user clicks on an external link such as e.g. a cable service 
icon on the GUI 220 of the device 11 (e.g., HDTV), then a hyper link 

10 associated with that icon sends a request including RIC of device 11 to the 
portal 908 with regional support, and that portal 908 based on the RIC 
determines region of the device 1 1 . 

In a first embodiment of redirection, the portal 908 then redirects the 
15 request to a cable service provider 910 in the local region (or any other desired 
region) associated with the RIC. For example, the portal 908 redirects the 
request to the URL of that cable service provider 910 (e.g., ATT) whereby the 
browser 410 in device 11 is redirected to that cable service provider 910. 
After the redirection by the portal 908 the cable service 910 web page is 
20 displayed on the device 1 1 for user interaction. The HTTP redirect comprises 
the device 1 1 sending to the server portal 908 a HTTP request (including RIC) 
for a URL for service, and based on the RIC in the request the portal 908 
provides a new URL of service provider portal 910 for service local to the 
device 11, wherein the browser 410 shows the contents of the web page of 
25 destination service provider 910 at the new URL on the device 1 1 . 

In a second embodiment of redirection, the portal 908 includes sets of 
html files 906 (e.g., including icons, names, URLs) associated with service 
providers 910. The html files are categorized based on RIC, such that there is 
30 a set of html files 906 corresponding to each RIC. Upon receiving an HTTP 
request with RIC from a device 11, the portal 908 uses the RIC to find the 
corresponding html files 906 in the portal 908, and sends the html files 906 
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associated with a destination portal 910 to the browser 410 of device 11 for 
display. The html files 906 include e.g. icon, name and URL of the destination 
portal 910 local to the device 11. Thereafter, when the user clicks on the 
icon/name of the destination portal displayed by the browser 410, the device 
5 1 1 is directed to the URL of the destination portal 910. 

In one implementation, two redirection programs 904 designated 
logoiconX and logonameX (for redirecting requests based on RIC) in the portal 
system 908 of external network 702 (FIG. 7) work for each service (e.g., cable, 

1 0 ISP, phone, etc.). The portal site 908 has access to a database of RICs 900 
and local service providers, so that the portal 908 can look up the 
corresponding service provider 910 for different RICs and redirect HTTP 
requests from each device 1 1 based on that device's RIC (for displaying the 
local service provider information for that region on device 11). For example, 

15 for Zip code or phone area RIC, the database 900 can be a lookup table of 
ZIP/local Service or Area Code/Local Service for each service, and for IP 
address, it can be a database of IP address/Local service provider/HTML name 
in the portal 908 (the home portal). The database 900 is updated by the 
sen/ice providers, such as cable providers or ISPs 910. 

20 

The RIC is embedded into the top-level home network homepage 250 
in the homepage generating process by the UIDGA 408. When a user 
accesses (e.g., clicks on) an RIC embedded HTTP link on the page 220, the 
HTTP request including an RIC is sent to the portal 908 in external network 

25 702. Upon receiving the HTTP request with embedded RIC: (1) in the first 
implementation of redirection described above, each redirect program 904 
(e.g., logoiconX and logonameX) on the portal 908 redirects the request to the 
URL of portal service 910 outside the portal 908 based on the. RICs (e.g., 
corresponding to the correct local service providers), or (2) in the second 

30 implementation of redirection described above each redirect program 904 uses 
said html files 906 for redirection, wherein e.g. the logoiconX program redirects 
the HTTP request from the device 11 (e.g., HDTV 102) to a html file 906 
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corresponding to the RIC of the device 11 in the HTTP request in the portal 
908, wherein the html file 906 includes a link to a destination service provider 
910 (e.g., Att.com) corresponding to the RIC. In one example, the portal 
908 sends the html files 906 associated with the destination portal 910 to the 
5 browser 410 of device 1 1 for display. The html files 906 include e.g. icon, 
name and URL of the destination portal 910 local to the device 1 1 . Thereafter, 
when the user clicks on the icon/name of the destination portal displayed by 
the browser 410, the device 1 1 is directed to the URL of the destination portal 
910. 

10 

The redirect programs can be programmed using any suitable program 
language, such as Java. There can be many destinations (e.g., 
URLs)available for one redirect program (e.g., LogoiconX or logonameX) to 
redirect a request to. The same redirect program can redirect using different 
15 kinds of RICs, for example, 5-digit Zip code, 9-digit Zip code, area code and 
IP address. Therefore, even mixed RICs can be used for the regional service 
support. 

Appendix 14 shows an example redirection program example in Java 
20 Servlet, wherein the redirection program is named go.java (same function as 
the logoiconX or logonameX program). The redirect URL to the program is . 
htt p://ip address/servlet/go, it will redirect the page immediately to, for example, 
the local service provider www.att.com . The RIC code can be easily added in 
the URL request like http:// ip address/servlet/go?arecode=408, then the 
25 following program can be changed to get the RIC code, search the database, 
get the correct URL and then redirect. 

Device icon spaces unused in the Top-level Home Network directory 
page 250 can be filled with service logos or icons and names from an external 
30 portal 908 (e.g., web site) provided by devices 704 in external network 702 
(FIG. 7). For example, there can be as many as 12 unused icon spaces in 
the page 250 (FIG. 16) for a minimum network including one Ul device 11. In 
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that case, there are a minimum of 12 sets of redirection programs on the portal, 
serving different HTML files containing logo-graphic and logo-name for the RIC 
based GUI 220 (FIG. 12). Said redirection programs can be implemented in 
different ways such as CGI script/program, Java servlet/program, ASP, etc.. 
5 In one example, the redirect program file names have a number from 1 to 12 
(e.g., logoiconl to Iogoicon12, logonamel to logoname12), and are accessed 
in sequential order starting with number 1 . 

A software agent in each Ul device (FIGS. 17-18) can make RICs 
10 available to the top-level home network homepage generator UIDGA. Then the 
RIC is embedded into the top-level home network homepage 250 (e.g., FIG. 
16) in the homepage generating process by the UIDGA 408. A default RIC 
can comprise e.g. all zeros. The home network can propagate identification 
code to Ul devices 1 1 using the same kind of RIC via e.g. a device-to-device 
15 control mechanism. 

In one implementation of the UIDGA for regional service, redirection 
program names in the portal server such as logoiconX (e.g., logoiconl, 
Iogoincon2, etc.) and logonameX (e.g., logonamel, logoname2, etc.) are used 

20 for the logo and name links in logo-items and name-items in the page 250. 
These redirection programs redirect the request to specific HTML files 
according to RIC. The names of the logoicon1.htm, logoname1.htm, 
Iogoicon2.htm, logoname2.htm, etc. files are not standardized. The redirect 
programs 904 (logoiconX and logonameX) in the portal server 908 redirect the 

25 request to destination URLs for each local service provider according to RIC 
(e.g., redirect portal query to a local cable portal site). 

4 In the above example, when a request for e.g. cable service from a 
device 11 is received by the Samsung portal, the portal uses the RIC 
30 information in the request and instead of providing the requested information 
from its own portal (e.g., yahoo.com or amazon.com), based on the RIC the 
portal redirects the request to the local cable service portal for services, such 
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that the service is localized based on the RIC regional information. 

<Top-level Homepage with External Links and Regional Service > 

5 As described, an aspect of providing regional service is supported in the 

top-level homepage generating process UIDGA, wherein an RIC is embedded 
into the HTTP request to external web servers 908 of network 702 in the top- 
level homepage 220. For example, if CGI type redirect program logoiconX and 
logonameX is utilized on the portal, the icon redirection URL can comprise e.g.: 
1 0 htt p://209. 1 57.0.2/cgi-bin/logoiconl?zip=95 1 34 , or 

htt p://209 .15 7.0.2/cg i-b in/logoiconl?zi p=95 1 3421 11 , or 
htt p://209.157.0.2/cgi-bin/logoiconl? i paddress=165.35.2.1 1 or 
http://20 9. 1 57.0.2/cgi-bin/ lo goiconl ?areaCo d e=408 . 

15 Similarly, the name redirection URL can comprise e.g.: 

htt p://209. 1 57.0.2/cgi-bin/logonamel?zip=95 1 34 , or 
htt p://209.157.0.2/cgi-bin/logonamel?zip=95 1342 1 11, or 
htt p://209,157.0.2/cgi-bin/logonamcl ?i paddress=165.35.2.1 , or 
htt p://209. 1 57.0.2/cgi-bin/logoname 1 ?areaCode=408 . 

20 

In the process of generating the top-level homepage, the UIDGA 
includes the RIC (e.g., Zip code) of the current Ul device 1 1 into the HTTP link 
(e.g., logoicon2?zip=95134 in FIG. 16). 

25 <Obtaining RICs> 

RICs can be obtained and set up in the following example two methods. 
The first method comprises one-time user configuration, as shown by 
example in FIGS. 17 and 19, wherein user can input RIC code such as Zip 
code or area code into a software agent 902 in a one-time setup step. The 
30 second method comprises automatic configuration with the help of service 
providers as shown in FIGS. 18 and 20. An RIC software agent 902 in the Ul 
device 11 (e.g., HDTV) can collect the RIC from the service provider 
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automatically, for example, using a trace route program 912 in the portal 908. 
In cases where the RIC comprises area code or Zip code, said software agent 
902 in a Ul device 11 (e.g., HDTV 102) can activate a dial-in phone call (wire- 
based or wireless, directly from the device or through the home network) to the 
5 home portal 908. The home portal 908 can obtain the area code e.g., using 
caller ID. The portal 908 can further map the area code to CIP code. The 
software agent 902 in the device 1 1 can obtain this information, such as the 
area code or zip code as RIC for use by the UIDGA 408. Where the RIC 
comprises a Device or Home Network IP Address, the software agent 902 in 
10 the HDTV 102 can obtain the IP address from the HDTV 102 directly or from 
home network, then use it as the RIC for the HDTV 102. 



In cases where the Service Provider IP Address is used as RIC, the IP 
address of service provider can be also used as RIC. First the RIC software 

15 agent 902 in HDTV 102 can call a TraceRoute program 912 in a portal site 908 
of external network 702, and retrieve the intermediate IP addresses list. Then 
the RIC software agent 902 selects the service provider 910 IP address from 
the list according to a criteria (e.g., the nearest IP address with a domain name 
ending with ".net" can be selected). Then this IP address, or even domain 

20 name, can be used as RIC. The example steps can be used regardless of the 
type of RIC. 

An example trace route program 912 is shown in Appendix 13, wherein 
after user configuration or automatic configuration, the RIC code is stored in 

25 the Ul device 1 1 (e.g., on a hard disk therein). The trace program 912 traces 
all the hubs, gateways and routers that a message goes through when it is 
traversing e.g. the Internet, to discover that for example the message has gone 
through the cable's head end router, allowing identification of the cable 
provider. If the request/message went through TCI's router, the portal 

30 redirects to TCI's portal. 



Though in the examples described herein redirection from a portal to 
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destination portals is based on a regional identification code, in another 
example redirection from one portal to another can based on other information 
in addition to, or in place of, a location or region of a device 11. Such other 
information can comprise e.g. information (e.g., age, education, etc.) about the 
5 user of a device 1 1 , wherein redirection to destination portals is based on such 
information. Further, the destination service provider can be either external 
to the portal 908, or within the destination portal 908 for providing services. 
Therefore, the redirection programs 904 in the portal 908 can redirect a 
request from a device 1 1 to a service providers within the portal 908, or to 
10 portals 910 external to the portal 908. 

Appendices 15, 6, 7, 8, 16, 17, 18, and 19 are illustrative examples for 
htm files for generating the top level home network user interface description 
and GUI in FIGS. 13 and 16 including external links with regional support. 

15 

Although the present invention has been described in considerable 
detail with regard to the preferred versions thereof, other versions are possible. 
Therefore, the appended claims should not be limited to the descriptions of 
the preferred versions contained herein. 

20 

Industrial Applicability 

The method and system for providing device communication arid control 
in a home network connected to an external network with regional support, 
according to the present invention can be applied to home networks having 
25 multi-media devices connected, such as PC, VCR, Camcorder, DVD, and 
HDTV, etc.. 
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Appendix 1- Top-Level Page Example 

<HTML> 
<HEAD> 

<TITLE>HN Devices Page</TITLE> 
</HEAD> 



<FRAMESET ROWS="2%, 47%,2%, 22.5%,2%,22.5%, 2%" border=0 
color=black> 

10 <NOFRAMES>Sorry does not support frames</NOFRAMES> 

<FRAMESET ROWS="100%,0%"> 

<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 

</FRAMESET> 
15 <FRAMESET 

COLS="1 .2%,23.5%,1 .2%,48.2%,1 .2%,23.5%,1 .2%"> 
<FRAMESET ROWS="100%,0%"> 

<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 
20 </FRAMESET> 

<FRAMESET ROWS="48%,4%,48%"> 
<FRAMESET ROWS="73%, 27%"> 
<FRAME SRC="http://10.1.1.1/icon.htm" SCROLLING="no" 
NORESIZE> 

25 <FRAME SRC=" http://10.1.1.1/name.htm" SCROLLING="no" 

NORESIZE> 

</FRAMESET> 

<FRAMESET ROWS="100%,0%"> 
<FRAME SRC="background.htm" SCROLLING="no" 

30 NORESIZE> 

</FRAMESET> 

<FRAMESET ROWS="73%, 27%" > 
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<FRAME SRC=" http://10.1.1.10/icon.htm" SCROLLING="no" 
NORESIZE> 

<FRAME SRC=" http.7/10.1.1.10/name.htm" SCROLUNG="no M 
NORESIZE> 
5 </FRAMESET> 
</FRAMESET> 

<FRAMESET ROWS="100%,0%"> 
<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 
10 </FRAMESET> 

<FRAMESET ROWS="73%, 27%" > 
<FRAME SRC=" http://10.1.22.1/icon.htm" SCROLLING="no" 
NORESIZE> 

<FRAME SRC=" http://1 0.1. 22.1 /name. htm" SCROLLING="no" 
15 NORESIZE> 

</FRAMESET> 

<FRAMESET ROWS="100%,0%"> 
<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 
20 </FRAMESET> 

<FRAMESET ROWS="48%,4%,48%"> 
< FRAMESET ROWS="73% ( 27%" > 
<FRAME SRC=" http://10.1.229.1/icon.htm" SCROLLING="no" 
NORESIZE> 

25 <FRAME SRC=" http://10.1.229.1/name.htm" SCROLLING="no" 

NORESIZE> 

</FRAMESET> 

<FRAMESET ROWS="1 00%,0%"> 
<FRAME SRC="background.htm" SCROLLING="no" 

30 NORESIZE> 

</FRAMESET> 

<FRAMESET ROWS="73%, 27%" > 
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<FRAME SRC=" http://10.30.30.1/icon.htm" SCROLLING="no" 
NORESIZE> 

<FRAME SRC=" http://10.30.30.1/name.htm" SCROLLING="no" 
NORESIZE> 
5 </FRAMESET> 
</FRAMESET> 

<FRAMESET ROWS="100%,0%"> 
<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 
10 </FRAMESET> 
</FRAMESET> 

<FRAMESET ROWS="100%,0%"> 

<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 
15 </FRAMESET> 
<FRAMESET 

COLS="1 .2%,23.5%,1 .2%,23.5%,1 .2%,23.5%,1 .2%,23.5%,1 .2%"> 
<FRAMESET ROWS="100%,0%"> 
<FRAME SRC="background.htm" SCROLLING="no" 

20 NORESIZE> 

</FRAMESET> 

<FRAMESET ROWS="73%, 27%" > 
<FRAME SRC=" http://10.41. 1.1/icon.htm" SCROLLING="no" 
NORESIZE> 

25 < FRAME SRC=" http://10.41. 1.1/name.htm" SCROLLING="no" 

NORESIZE> 

</FRAMESET> 

<FRAMESET ROWS="100%,0%"> 
<FRAME SRC="background.htm" SCROLLING="no" 

30 NORESIZE> 

</FRAMESET> 

<FRAMESET ROWS='73%, 27%" > 
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<FRAME SRC=" http://10.41.21.1Aicon.htm" SCROLLING="no" 
NORESIZE> 

<FRAME SRC=" http://10.41. 21. 1/name.htm" SCROLLING="no" 
NORESIZE> 
5 </FRAMESET> 

<FRAMESET ROWS«"100%,0%"> 

<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 

</FRAMESET> 
10 <FRAMESET ROWS="73%, 27%" > 

<FRAME SRC=" http://10.45.1.1/icon.htm" SCROLLING="no" 
NORESIZE> 

<FRAME SRC=" http://10.45.1. 1/name.htm" SCROLLING="no" 
NORESIZE> 
15 </FRAMESET> 

<FRAMESET ROWS="100%,0%"> 
<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 

</FRAMESET> 
20 <FRAMESET ROWS="73%, 27%" > 

<FRAME SRC=" http://10.100.1.1/icon.htm" SCROLLING="no" 
NORESIZE> 

<FRAME SRC=" http://10.1001. 1/name.htm" SCROLLING="no" 
NORESIZE> 
25 </FRAMESET> 

<FRAMESET ROWS="100%,0%"> 

<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 

</FRAMESET> 
30 </FRAMESET> 

<FRAMESET ROWS="100%,0%"> 

<FRAME SRC="background.htm" SCROLLING="no" 
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NORESIZE> 

</FRAMESET> 
<FRAMESET 

COLS="1.2%,23.5%,1.2%,23.5%,1.2%,23.5%,1.2%,23.5%,1.2%"> 
5 <FRAMESET ROWS="100%,0%"> 

<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 

</FRAMESET> 

<FRAMESET ROWS="73%, 27%" > 
10 <FRAME SRC=" http://10.122.22.1/eia.htm" SCROLLING="no" 

NORESIZE> 

<FRAME SRC=" http://10.122.22.1/eia.htm" SCROLLING="no" 
NORESIZE> 

</FRAMESET> 
15 <FRAMESETROWS="100%,0%"> 

<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 

</FRAMESET> 

<FRAMESET ROWS=*73%, 27%" > 
20 <FRAME SRC=" http://10.122.122.122/icon.htm" SCROLLING="no" 

NORESIZE> 

<FRAME SRC=" http://10.122.122.122/name.htm" SCROLLING="no" 
NORESIZE> 

</FRAMESET> 
25 <FRAMESETROWS="100%,0%"> 

<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 

</FRAMESET> 

<FRAMESET ROWS="73%, 27%" > 
30 <FRAME SRC=" http://10.122.122.123/icon.htm" SCROLLING="no" 

NORESIZE> 

< FRAME SRC=" http://10.122.122.123/name.htm" SCROLLING="no" 
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NORESIZE> 

</FRAMESET> 

<FRAMESET ROWS="100%,0% M > 

<FRAME SRC="background.htm" SCROLLING="no" 

5 NORESIZE> 

</FRAMESET> 

<FRAMESET ROWS="73%, 27%" > 
<FRAME SRC=" http://10.122.122.124/icon.htm" SCROLLING="no" 
NORESIZE> 

10 <FRAME SRC=" http://10.122.122.124/name.htm" SCROLLING="no" 

NORESIZE> 

</FRAMESET> 

<FRAMESET ROWS="100%,0%"> 

<FRAME SRC="background.htm" SCROLLING="no" 

15 NORESIZE> 

</FRAMESET> 
</FRAMESET> 

<FRAMESET ROWS="100%,0%"> 

<FRAME SRC="background.htm" SCROLLING="no" 

20 NORESIZE> 

</FRAMESET> 
</FRAMESET> 

<BODY BGCOLOR="#FFFFF0" TEXT="#000070" LINK="#0000ff' 
ALINK="#FF0O00" VLINK="#007986"> 
25 </BODY> 
</HTML> 
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Appendix 2- Background.htm example 

<HTML> 
<HEAD> 

5 <TITLE>Background</TITLE> 

</HEAD><BODYBGCOLOR="#007986"></BODY> 



</HTML> 
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Appendix 3 - lcon.htm example 

<HTML> 
<HEAD> 

5 <TITLE> Device lcon<TITLE> 

</HEAD> 

<BODY BGCOLOR="#FFFFF0" TEXT="#000070" LINK="#0000ff' 
ALINK="#FF000O" VLINK="#007986"> 
10 <br><br><CENTER> 

<IMG SRC="icon.gif border=0> 

</CENTER> 

</BODY> 



15 



</HTML> 
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Appendix 4 - Name. htm example 

<HTML> 
<HEAD> 

<TITLE>Device Name<fTITLE> 
</HEAD> 



<BODY BGCOLOR="#FFFFF0" TEXT= M #000070" LINK="#0000fP' 
ALINK="#FFO00O" VLINK='*#007986"> 
10 <CENTER><FONT size=+0>Samsung Device</font></CENTER> 

</BODY> 
</HTML> 
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Appendix 5 - Top-Level Page Example TLNUID (index.htm) 

<HTML> 
<HEAD> 



<TITLE>HN Devices Page</TITLE> 
</HEAD> 



<FRAMESET ROWS="2%, 47%,2%, 22.5%,2%,22.5%, 2%" 
10 BORDER=0 COLOR=black> 

<NOFRAMES>Sorry does not support frames</NOFRAMES> 
<FRAMESET ROWS="1 00%,0%"> 

<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 
15 </FRAMESET> 
<FRAMESET 
COLS="1 .2%.23.5%,1 .2%,48.2%,1 .2%,23.5%,1 .2%"> 
<FRAMESET ROWS="100%,0%"> 

<FRAME SRC="background.htm" SCROLLING="no" 

20 NORESIZE> 

</FRAMESET> 

<FRAMESET ROWS="48%,4%,48%"> 
<FRAMESET ROWS="73%, 27%"> 
<FRAME SRC="http://10.1.1.2/icon.htm" SCROLLING="no" 
25 NORESIZE> 

<FRAME SRC="http://10.1.1.2/name.htm" SCROLLING="no" 
NORESIZE> 

</FRAMESET> 

<FRAMESET ROWS="100%,0%"> 
30 <FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 

</FRAMESET> 
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<FRAMESET ROWS="73%, 27%" > 
<FRAME SRC="http://10.1.1.63/icon.htm" SCROLLING="no" 
NORESIZE> 

<FRAME SRC="http://10.1.1.63/name.htm" SCROLLING="no" 
5 NORESIZE> 

</FRAMESET> 
</FRAMESET> 

<FRAMESET ROWS="100%,0%"> 

< FRAME SRC="background.htm" SCROLUNG= ,, no" 

10 NORESIZE> 

</FRAMESET> 

<FRAMESET ROWS="73%, 27%" > 
<FRAME SRC="icon.htm" SCROLLING="no" NORESIZE> 
<FRAME SRC="name.htm" SCROLLING="no" NORESIZE> 
15 </FRAMESET> 

<FRAMESET ROWS="100%,0%"> 

< FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 

</FRAMESET> 
20 <FRAMESET ROWS="48%,4%,48%"> 

<FRAMESET ROWS='73%, 27%" > 
< FRAME SRC="http://10.41.l2/icon.htm" SCROLLING="no" 
NORESIZE> 

<FRAME SRC="http://10.41.1.2/name.htm" SCROLLING="no" 
25 NORESIZE> 

</FRAMESET> 

<FRAMESET ROWS="100%,0%"> 
<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 
30 </FRAMESET> 

<FRAMESET ROWS="73%, 27%" > 
<FRAME SRC="http://10.10.1.2/icon.htm" SCROLLING="no" 
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NORESIZE> 

<FRAME SRC="http://10.10.1.2/name.htm" SCROLLING="no M 
NORESIZE> 

</FRAMESET> 
5 </FRAMESET> 

<FRAMESET ROWS="100%,0%"> 

<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 

</FRAMESET> 
10 </FRAMESET> 

<FRAMESET ROWS="100%,0%"> 

<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 

</FRAMESET> 
15 <FRAMESET 

COLS="1.2% > 23.5%,1.2% > 23.5%,1.2%,23.5%,1.2%,23.5%,1.2%"> 
<FRAMESET ROWS="1 00%,0%"> 
<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 
20 </FRAMESET> 

<FRAMESET ROWS='73%, 27%" > 
<FRAME SRC="http://10.1.1.200/icon.htm" SCROLLING="no" 
NORESIZE> 

<FRAME SRC="http://10.1.1.200/name.htm" SCROLLING="no" 
25 NORESIZE> 

</FRAMESET> 

<FRAMESET ROWS="100%,0%"> 

<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 
30 </FRAMESET> 

< FRAMESET ROWS='73%, 27%" > 
<FRAME SRC="http://10.1.10.20/icon.htm" SCROLLING="no" 
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NORESIZE> 

<FRAME SRC="http://10.1.10.20/name.htm" SCROLLING="no" 
NORESIZE> 

</FRAMESET> 
5 <FRAMESETROWS="100%,0%"> 

<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 

</FRAMESET> 

<FRAMESET ROWS="73%, 27%" > 
10 <FRAME SRC="http://10.1.99.2/icon.htm" SCROLLING="no" 

NORESIZE> 

<FRAME SRC="http://10.1.99.2/name.htm" SCROLLING="no" 
NORESIZE> 

</FRAMESET> 
15 <FRAMESETROWS="100%,0%"> 

<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 

</FRAMESET> 

<FRAMESET ROWS="73%. 27%" > 
20 <FRAME SRC="http://10.1.99.9/icon.htm" SCROLLING="no" 

NORESIZE> 

<FRAME SRC="http://10.1.99.9/name.htm" SCROLLING="no" 
NORESIZE> 

</FRAMESET> 
25 <FRAMESETROWS="100%,0%"> 

<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 

</FRAMESET> 
</FRAMESET> 
30 <FRAMESETROWS="100%,0%"> 

<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 
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</FRAMESET> 
<FRAMESET 

COLS=" 1 .2%,23.5%, 1 .2%,23.5%, 1 .2%.23.5%.1 .2%,23.5%, 1 .2%"> 
<FRAMESET ROWS="100%,0%"> 
5 <FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 

</FRAMESET> 

<FRAMESET ROWS="73%, 27%" > 
<FRAME SRC="http://209.157.0.2/logoicon1.htm" SCROLLING="no" 
10 NORESIZE> 

<FRAME SRC="http://209.157.0.2/logoname1.htm" SCROLLING="no" 
NORESIZE> 

</FRAMESET> 

<FRAMESET ROWS="100%,0%"> 
15 <FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 

</FRAMESET> 

<FRAMESET ROWS="73%, 27%" > 
<FRAME SRC="http://209.157.0.2/logoicon2.htm" SCROLLING="no" 
20 NORESIZE> 

< FRAME SRC="http://209.157.0.2/logoname2.htm" SCROLLING="no" 
NORESIZE> :> 
</FRAMESET> 

<FRAMESET ROWS="100%,0%"> 
25 <FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 

</FRAMESET> 

<FRAMESET ROWS="73%, 27%" > 
<FRAME SRC="http://209.157.0.2/logoicon3.htm" SCROLLING="no" 
30 NORESIZE> 

< FRAME SRC="http://209.157.0.2/logoname3.htm" SCROLLING="no" 
NORESIZE> 
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</FRAMESET> 

<FRAMESET ROWS="100%,0%"> 
<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 
5 </FRAMESET> 

<FRAMESET ROWS='73%, 27%" > 
<FRAME SRC="http://209.157.0.2/logoicon4.htm'' SCROLLING="no" 
NORESIZE> 

<FRAME SRC="http://209.157.0.2/logoname4.htm" SCROLLING="no' 
10 NORESIZE> 

</FRAMESET> 

<FRAMESET ROWS="100%,0%"> 
<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 
15 </FRAMESET> 
</FRAMESET> 

<FRAMESET ROWS="100%,0%"> 

<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 
20 </FRAMESET> 
</FRAMESET> 

» 

<BODY BGCOLOR="#FFFFF0" TEXT="#000070" LINK="#0000ff" 
ALINK="#FF0000" VLINK="#007986"> 

25 

</BODY> 
</HTML> 
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Appendix 6 - background.htm example 

<HTML> 

5 <HEAD> 

<TITLE>Background</TITLE> 
</HEAD> 

<BODYBGCOLO R="#0079 86"></BO D Y> 



10 



</HTML> 
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Appendix 7 - icon. htm example 

<HTML> 

5 <HEAD> 

<TITLE>Device lcon</TITLE> 
</HEAD> 

<BODY BGCOLOR="#FFFFF0" TEXT="#000070" LINK="#0000fP' 
10 ALINK="#FF0000" VLINK="#007986"> 
<BR><BR> 
<CENTER> 

<A HREF="index.htm" TARGET="_blank"><IMG SRC="icon.gif 
BORDER=0></A> 
15 </CENTER> 
</BODY> 

</HTML> 
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Appendix 8 • Example name.htm 

<HTML> 

5 <HEAD> 

<TITLE>Device Name<fl"ITLE> 
</HEAD> 

<BODY BGCOLOR="#FFFFF0" TEXT="#000070" LINK="#0000fT 
10 ALINK="#FF0000" VLINK="#007986"> 
<CENTER> 

<FONT SIZE=+0>HDTV Master Bedroom</FONT></CENTER> 
</BODY> 

15 </HTML> 
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Appendix 9 - Example logoicon1.htm 

<HTML> 
<HEAD> 

5 <TITLE>Logo Icon 1 </TITLE> 

</HEAD> 

<BODY BGCOLOR="#FFFFF0" TEXT="#000070" LINK="#0000ff' 
ALINK="#FF0000"VLINK="#007986"> 
10 <CENTER> 

<A HREF="http://209. 157.0.2" TARGET="_blank"><IMG 
SRC="hww1.gif BORDER=0></A> 
</CENTER> 
</BODY> 

15 

</HTML> 
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Appendix 10 - Example logoname1.htm 

<HTML> 

5 <HEAD> 

<TITLE>Logo Name 1 </TITLE> 
</HEAD> 

<BODY BGCOLOR="#FFFFF0" TEXT="#000070" LINK="#0000ff' 
10 ALINK="#FF0000" VLINK="#007986"> 
<CENTER> 

<A HREF="http://209. 157.0.2" target="_blank">Home Wide Web</A> 

</CENTER> 

</BODY> 

15 

</HTML> 
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Appendix 11 • Example logoicon2.htm 

<HTML> 

5 <HEAD> 

<TITLE>Logo Icon 2</TITLE> 
</HEAD> 

<BODY BGCOLOR="#FFFFF0" TEXT="#000070" LINK="#O00Or 
10 ALINK="#FF0000" VLINK="#007986"> 
<BR><BR> 
<CENTER> 

<A HREF="http://204.71 .200.75" TARGET="_blank"><IMG 
SRC="yahoo.gif ' BORDER=0></A> 
15 </CENTER> 
</BODY> 

</HTML> 
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Appendix 12 - Example logoname2.htm 

<HTML> 

5 <HEAD> 

<TITLE>Logo Name 2</TITLE> 
</HEAD> 

<BODY BGCOLOR="#FFFFF0" TEXT="#000070" LINK="#0000fP' 
10 ALINK="#FF0000" VLINK="#007986"> 
<CENTER> 

<A HREF="http://204.71 .200.75" TARGET="_blank">Directory 
Services</A> 

</CENTER> 
15 </BODY> 

</HTML> 
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Appendix 13 - Perl Example Program for Trace Route 

An Perl trace route example program for regional sen/ice using service 
provider IP address as RIC. 

5 

#!/usr/bin/perl 

# full path to "traceroute" executable 
$traceroute = 7usr/sbin/traceroute"; 

# path to the script 

10 $url = 7cgi-bin/traceroute.cgi"; 

# your title 

$title ='Traceroute Script"; 

if ($ENV{'CONTENT_LENGTH'} ne ") { 
15 read(STDIN, Sbuffer, $ENV{'CONTENT_LENGTH'}); 

@pairs = split(/&/, $buffer); 
foreach $pair (@pairs) 
{ 

($name. $value) = split(/=/, $pair); 
20 $value =~ tr/+/ /; 

$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg; 
$value =~ s/~!/ ~!/g; 
$FORM{$name} = $value; 

} 

25 } 

$FORM{'host'} =~ s/(\;)//g; 

print "Content-type:text/html\n\n"; 

print "<HTML>\n <HEAD><TITLE>$title</TITLE></HEAD><BODY 
BGCOLOR=\"#FFFFFR" LINK=\"#FFFFFF\" VLINK=\"#FFFFFR" 
30 ALI N K=\"#F FFF FF\"> "; 

if ($FORMChosf} eq "){ 
print «EOFHTML; 
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<FORM METHOD="POSr ACTION="$url ,, > 
<TABLE W1DTH="350" CELLPADDING="0" CELLSPACING="0" 
BORDER="0"> 

<TR ALIGN="CENTER"><TD 
5 BGCOLOR="#ffbc2a"> <BR><INPUT TYPE-TEXT' SIZE="18" 
MAXSIZE="40" NAME="host" 
VALUE-'domain.com"><BR> </TD><TD 

BGCOLOR="#000000"> <BR><INPUT TYPE="SUBMIT" 

VALUE="CHECK"><BR> <n"D></TR> 
10 <TR><TD ALIGN-'CENTER" COLSPAN="2" 

BGCOLOR="#CCCCCC"><FONT COLOR="#FFFFFF" SIZE="-2">AII rights 

reserved. <A HREF="http://www.fastgraf.com">Fastgraf</A> (c) 

1 998</FONT></TD></TR> 
</TABLE> 
15 EOFHTML 

} 

else 
{ 

$txt = "$traceroute SFORMfhost'}"; 
20 print «EOFHTML; 

<TABLE WIDTH= M 100%" HEIGHT="40"> 
<TR><TD BGCOLOR="#ffbc2a ,, ><B>$title</B><n'Dx/TR> 
</TABLE> 
<PRE>$txt</PRE> 
25 EOFHTML 
} 

print "</BODY></HTML>"; 
exit 0; 
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Appendix 14 - Example Redirection Programs 

package redirect; 
import javax.servlet.*; 
5 import javax.servlet.http.*; 

import java.io.*; 
import java.util.*; 

public class go extends HttpServlet { 

10 

//Initialize global variables 

public void init(Serv!etConfig config) throws ServletException { 
super.init(config); 

} 

15 

//Process the HTTP Get request 

public void doGet(HttpServletRequest request, HttpServletResponse 
response) throws ServletException, lOException { 

response.setStatus(response.SC_MOVED_TEMPORARILY); 
20 response.setHeader("Location", "http://www.att. com"); 

} 

//Process the HTTP Post request 

public void doPost(HttpServletRequest request, HttpServletResponse 
25 response) throws ServletException, lOException { 

response.setStatus(response.SC_MOVED_TEMPORARILY); 
response.setHeader("Location'\ "http://www.att.com"); 

} 



30 



//Get Servlet information 
public String getServletlnfo() { 
return "redirect.go Information"; 
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Appendix 15 - Top-Level Page Example TLNUID (index.htm) 

<HTML> 
<HEAD> 

5 

<TITLE>HN Devices Page<mTLE> 
</HEAD> 

<FRAMESET ROWS="2%, 47%,2%, 22.5%,2%,22.5%, 2%" 
10 BORDER=0 COLOR=black> 

<NOFRAMES>Sorry does not support frames</NOFRAMES> 
<FRAMESET ROWS="100%,0%"> 

<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 
15 </FRAMESET> 
<FRAMESET 
COLS="1 .2%,23.5%, 1 .2%,48.2%, 1 .2%,23.5%, 1 .2%"> 
<FRAMESET ROWS="100%,0%"> 

<FRAME SRC="background.htm" SCROLLING="no" 

20 NORESIZE> 

</FRAMESET> 

<FRAMESET ROWS="48%,4%,48%"> 
<FRAMESET ROWS="73%, 27%"> 
<FRAME SRC="http://10.1.1.2/icon.htm" SCROLLING="no" 
25 NORESIZE> 

<FRAME SRC="http://10.1.1.2/name.htm" SCROLLING="no" 
NORESIZE> 

</FRAMESET> 

< FRAMESET ROWS="100%,0%"> 
30 <FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 

</FRAMESET> 
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<FRAMESET ROWS="73%, 27%" > 
<FRAME SRC="http://10.1.1.63/icon.htm" SCROLLING="no" 
NORESIZE> 

<FRAME SRC="http://10.1.1.63/name.htm" SCROLLING="no" 
5 NORESIZE> 

</FRAMESET> 
</FRAMESET> 

<FRAMESET ROWS="100%,0%"> 
< FRAME SRC="background.htm" SCROLLING="no" 

10 NORESIZE> 

</FRAMESET> 

<FRAMESET ROWS="73%, 27%" > 
<FRAME SRC="icon.htm" SCROLLING="no" NORESIZE> 
<FRAME SRC="name.htm" SCROLLING="no" NORESIZE> 
15 </FRAMESET> 

<FRAMESET ROWS="100%,0%"> 

<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 

</FRAMESET> 
20 <FRAMESET ROWS="48%,4%,48%"> 

<FRAMESET ROWS="73%, 27%" > 
<FRAME SRC="http://10.41.1.2/icon.htm" SCROLLING="no" 
NORESIZE> 

<FRAME SRC="http://10.41.1.2/name.htm" SCROLLING="no" 
25 NORESIZE> 

</FRAMESET> 

<FRAMESET ROWS="100%,0%"> 
<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 
30 </FRAMESET> 

< FRAMESET ROWS="73%, 27%" > 
<FRAME SRC="http://10.10.1.2/icon.htm" SCROLLING="no" 
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NORESIZE> 

<FRAME SRC="http://10.10.1.2/name.htm" SCROLLING="no" 
NORESIZE> 

</FRAMESET> 
5 </FRAMESET> 

<FRAMESET ROWS="100%,0%"> 

<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 

</FRAMESET> 
10 </FRAMESET> 

<FRAMESET ROWS="100%,0%"> 

<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 

</FRAMESET> 
15 <FRAMESET 

COLS="1 .2%,23.5%, 1 .2%,23.5%, 1 .2%,23.5%,1 .2%,23.5%, 1 .2%"> 
<FRAMESET ROWS="100%,0%"> 

<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 
20 </FRAMESET> 

<FRAMESET ROWS="73%, 27%" > 
<FRAME SRC="http://10.1.1.200/icon.htm" SCROLLING="no" 
NORESIZE> 

<FRAME SRC="http://10.1.1.200/name.htm" SCROLLING="no" 
25 NORESIZE> 

</FRAMESET> 

<FRAMESET ROWS="100%,0%"> 

<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 
30 </FRAMESET> 

<FRAMESET ROWS="73%. 27%" > 
<FRAME SRC="http://10.1.10.20/icon.htm" SCROLLING="no" 
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NORESIZE> 

<FRAME SRC="http://10.1.10.20/name.htm" SCROLLING="no" 
NORESIZE> 

</FRAMESET> 
5 <FRAMESET ROWS="1 00%,0%"> 

<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 

</FRAMESET> 

<FRAMESET ROWS="73%, 27%" > 
10 <FRAME SRC="http://10.1.99.2/icon.htm" SCROLLING="no ,, 

NORESIZE> 

<FRAME SRC="http://10.1.99.2/name.htm" SCROLLING="no" 
NORESIZE> 

</FRAMESET> 
1 5 <FRAMESET ROWS="1 00%,0%"> 

<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 

</FRAMESET> 

<FRAMESET ROWS='73%, 27%" > 
20 <FRAME SRC="http://10.1.99.9/icon.htm" SCROLLING="no" 

NORESIZE> 

<FRAME SRC="http://10.1.99.9/name.htm" SGROLLING="no" 
NORESIZE> 

</FRAMESET> 
25 <FRAMESETROWS="100%,0%"> 

<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 

</FRAMESET> 
</FRAMESET> 
30 <FRAMESETROWS="100%,0%"> 

<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 
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</FRAMESET> 
< FRAMESET 

COLS="1 .2%,23.5%,1 .2%,23.5%,1 .2%,23.5%,1 .2%,23.5%,1 .2%"> 
<FRAMESET ROWS="100%,0%"> 
5 <FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 

</FRAMESET> 

<FRAMESET ROWS="73%, 27%" > 
<FRAME SRC="http://209. 1 57.0.2/logoicon 1 ?zip=951 34" 

10 SCROLLING="no" NORESIZE> 

<FRAME SRC="http://209.157.0.2/logoname1?zip=95134" 
SCROLLING="no" NORESIZE> 
</FRAMESET> 

<FRAMESET ROWS="100%,0%"> 
15 <FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 

</FRAMESET> 

<FRAMESET ROWS="73%, 27%" > 
<FRAME SRC="http://209.157.0.2/logoicon2?zip=95134" 
20 SCROLLING="no" NORESIZE> 

<FRAME SRC="http://209.157.0.2/logoname2?zip=95134" 
SCROLLING="no" NORESIZE> 
</FRAMESET> 

<FRAMESET ROWS="100%,0%"> 
25 <FRAME SRO"background.htm" SCROLLING="no" 

NORESIZE> 

</FRAMESET> 

<FRAMESET ROWS="73%, 27%" > 
<FRAME SRC="http://209.157.0.2/logoicon3?zip=95134" 
30 SCROLLING="no" NORESIZE> 

<FRAME SRC="http://209.157.0.2/logoname3?zip=95134" 
SCROLLING="no" NORESIZE> 
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</FRAMESET> 

<FRAMESET ROWS="100%.0%"> 
<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 
5 </FRAMESET> 

<FRAMESET ROWS="73%, 27%" > 
<FRAME SRC="http://209.157.0.2/logoicon4?zip=95134" 
SCROLLING="no" NORESIZE> 

< FRAME SRC="http://209.157.0.2/logoname4?zip=95134" 
10 SCROLLING="no" NORESIZE> 
</FRAMESET> 

<FRAMESET ROWS= n 100%,0%"> 

<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 
15 </FRAMESET> 
</FRAMESET> 

<FRAMESET ROWS="100%,0%"> 

<FRAME SRC="background.htm" SCROLLING="no" 

NORESIZE> 
20 </FRAMESET> 
</FRAMESET> 

<BODY BGCOLOR="#FFFFF0" TEXT="#000070" LINK="#0000ff' 
ALINK="#FF0000" VLINK="#007986"> 

25 

</BODY> 
</HTML> 
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Appendix 16 - Example logoicon1.htm 

<HTML> 

5 <HEAD> 

<TITLE>Logo Icon 1</TITLE> 
</HEAD> 

<BODY BGCOLOR="#FFFFF0" TEXT="#000070" LINK="#0000ff' 
10 ALINK="#FF000O" VLINK="#007986"> 
<CENTER> 

<A HREF="http://209.157.0.2/servlets/logoicon1?zip=9513421 1 1" 
TARGET="_blank"><IMG SRC="hww1 gif ' BORDER=0></A> 
</CENTER> 
15 </BODY> 

</HTML> 
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Appendix 17 • Example logoname1.htm 

<HTML> 

5 <HEAD> 

<TITLE>Logo Name 1</TITLE> 
</HEAD> 

<BODY BGCOLOR="#FFFFF0" TEXT="#000070" LINK="#0000ff' 
1 0 AUNK="#FF0000" VLINK="#007986"> 
<CENTER> 

<A HREF="http://209.157.0.2/servlets/logoicon1?zip=9513421 11" 
target="_blank">Home Wide Web</A> 
</CENTER> 
15 </BODY> 

</HTML> 
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Appendix 18 - Example logoicon2.htm 

<HTML> 

5 <HEAD> 

<TITLE>Logo Icon 2</TITLE> 
</HEAD> 

<BODY BGCOLOR="#FFFFF0" TEXT="#000070" LINK="#0000ff" 
10 ALINK="#FF0000" VLINK="#007986"> 
<BR><BR> 
<CENTER> 

<A HREF="http://204.71 .200.75/servlets/logoicon1 ?zip=951 3421 11" 
TARGET="_blank"><IMG SRC="yahoo.gif BORDER=0></A> 
15 </CENTER> 
</BODY> 

</HTML> 
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Appendix 19 • Example logoname2.htm 

<HTML> 

5 <HEAD> 

<TITLE>Logo Name 2</TITLE> 
</HEAD> 

<BODY BGCOLOR="#FFFFF0" TEXT="#000070" LINK="#OO00r 
10 ALINK="#FF0000" VLINK="#007986"> 
<CENTER> 

<A HREF="http://204.71 .200.75/servlets/logoicon1?zip=951 34211 1" 
TARGET="_blank">Directory Services</A> 
</CENTER> 
15 </BODY> 

</HTML> 
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What is claimed is: 

1 . A method for providing user interfaces in a first network including 
first devices interconnected via a communication medium , and at least one 

5 interface device connecting said first network to at least a second network 
providing sen/ices, the user interfaces for controlling the devices that are 
currently connected to the first network and furnishing services of the second 
network to at least a user, comprising the steps of: 

in each of one or more first devices in the first network: 
10 (a) obtaining information from one or more of said first devices 

currently connected to the first network, said information including device 
information; and 

(b) generating a user interface description including: 

(1 ) at least one reference associated with the device information of 
1 5 each of said one or more first devices, 

(2) at least a redirection identification code (RIC) corresponding to 
that first device, and 

(3) at least one reference associated with the services provided by 
the second network. 

20 

2. The method of claim 1 , wherein the first network comprises a 
1394 network, and the second network comprises a non-1394 network. 

3. The method of claim 1 , wherein the interface device comprises 
25 a gateway device. 

4. The method of claim 1, wherein the second network comprises 
a plurality of interconnected second devices providing one or more services. 

30 5. The method of claim 4, wherein each of said second devices 

comprises at least one computer system programmed to provide services. 



WO 01/37581 



114 



PCT/KR00/01330 



6. The method of claim 4, wherein: 

the second network comprises the Internet, and 
at least one of said second devices providing services comprises one 
or more web servers providing services. 

5 

7. The method of claim 6, wherein a service provided by at least 
one of the devices connected to the second network comprises a web site 
service. 

10 8. The method of claim 1, wherein each reference in the user 

interface description associated to services provided by the second network 
comprises at least one hyper-link to service information in the second network. 

9. The method of claim 1 further including the step of: 
15 (c) displaying a user interface based on said user interface 

description on a device connected to the first network capable of displaying a 
user interface, for user control of said first devices and communication with the 
second network. 

20 1 0. The method of claim 9, wherein the step of displaying each user 

interface further includes the steps of: 

using each reference in the corresponding user interface 
description to access the associated information in each first device; 
using each reference associated with services provided by the 
25 second network to access corresponding service information; 

generating the user interface including: (1) information 
corresponding to each first device using the accessed information in 
each first device, and (2) service information; and 

displaying the user interface on said device capable of displaying 
30 a user interface. 

1 1 . The method of claim 1 0, wherein: 
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the step of accessing service information includes the steps of 
using each reference associated with services provided by the second 
network to access corresponding service information based on the RIC 
in the user interface description; and 
5 the step of generating the user interface further includes 

generating the user interface including service information based on 
said RIC. 

12. The method of claim 1, wherein the step of generating a user 
10 interface description further comprises the steps of: associating a hyper-link 
with the device information of one or more of said first devices, and associating 
at least a hyper-text link with the service information provided by the second 
network. 

15 13. The method of claim 1, wherein: (1) the device information in 

each first device in the first network includes a user interface description for 
user interaction with that device, and (2) the service information in the second 
network includes a plurality of user interface descriptions for user interaction 
with a plurality of services based on RICs. 

20 

14. The method of claim 1 , wherein each reference associated with 
services provided by the second network comprises at least one hyper-link to 
service information in the second network, wherein the service information 
comprises at least identification information representing services based on 

25 RICs. 

15. The method of claim 14, wherein the identification information 
comprises at least a logo information files including links to a logo graphics 
representing the services. 

30 

16. The method of claim 1 , wherein the second network includes at 
least a first portal for providing services, and a reference in the user interface 
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description associated with services provided by the second network 
comprises at least one hyper-link to said first portal, wherein the first portal 
includes service information comprising at least identification information 
representing said services provided by the first portal. 

5 

17. The method of claim 16, wherein said identification information 
in the first portal further comprises at least hyper-link to service information 
provided by a second portal in the second network. 

10 18. The method of claim 17, wherein said identification information 

in the first portal further comprises at a least hyper-link to service information 
provided by at least a second portal in the second network based on RIC. 

19. The method of claim 17, wherein: 

15 the second network comprises a plurality of interconnected computer 

systems programmed to provide services; 

the first portal comprises one or more of said computer systems 
providing services of the first portal; and 

the second portal comprises one or more of said computer systems 
20 providing services of the second portal. 

20. The method of claim 1 , wherein the second network includes at 
least a first portal and at least a destination service provider for providing 
services, the method further comprising the steps of: 

25 at least a first device requesting service from the second network by 

sending a request including an RIC to the first portal using a reference in the 
user interface description, 

the first portal determining a destination service provider based on the 
received RIC, and 

30 the first portal redirecting the request to the destination service provider. 

21 . The method of claim 20, wherein the destination service provider 
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in the second network is internal to the first portal. 

22. The method of claim 20, wherein the destination service provider 
in the second network is external to the first portal. 

5 

23. The method of claim 20, wherein a reference associated with 
services provided by the second network comprises at least one hyper-link to 
said first portal, wherein the first portal includes service information comprising 
at least redirection information based on RICs to services provided by other 

10 service providers in the second network. 

24. The method of claim 20, wherein the first portal further includes 
a list of RICs and corresponding destination service provider portal addresses, 
such that the steps of determining a destination service provider further 

15 includes the steps of looking up in said list a destination service provider portal 
address corresponding to a received RIC, and redirecting the request to said 
destination service provider portal address. 

25. The method of claim 24, wherein each destination service 
20 provider address comprises a URL. 

26. The method of claim 1 , further comprising the steps* of obtaining 
an RIC for at least one first device from a user. 

25 27. The method of claim 1, further comprising the steps of 

automatically obtaining an RIC for at least one first device within the first 
network. 

28. The method of claim 1 , wherein for at least one first device the 
30 corresponding RIC comprises an identifier representing the geographical 
region of the first device. 
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29. A network system for performing services, comprising: 

a first network of first devices interconnected via a communication 
medium; 

an interface device connecting the first network to an external network 
5 providing services, 

a user interface description generation agent in at least one of said first 
devices configured for: 

(a) obtaining information from one or more of said first devices 
currently connected to the local network, said information including device 

10 information; and 

(b) generating a user interface description including: 

(1 ) at least one reference associated with the device information of 
each of said one or more first devices, 

(2) at least a redirection identification code (RIC) corresponding to 
1 5 that first device, and 

(3) at least one reference associated with the services provided by 
the external network. 

30. The network system of claim 29, wherein the first network 
20 comprises a 1394 network, and the external network comprises a non-1394 

network. 

31. The network system of claim 29, wherein the interface device 
comprises a gateway device. 

25 

32. The network system of claim 29, wherein the external network 
comprises a plurality of interconnected second devices providing one or more 
services. 



30 



33. The network system of claim 32, wherein each of said second 
devices comprises at least one computer system programmed to provide 
services. 
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34. The network system of claim 32, wherein: 
the second network comprises the Internet, and 

at least one of said second devices providing services comprises one 
5 or more web servers providing services. 

35. The network system of claim 34, wherein a service provided by 
at least one of the devices connected to the second network comprises a web 
site service. 

10 

36. The network system of claim 39, wherein each reference in the 
user interface description associated to services provided by the external 
network comprises at least one hyper-link to service information in the external 
network. 

15 

37. The network system of claim 29, wherein: 

at least one of the first devices in the first network includes a user 
interface device capable of displaying a user interface, the user interface 
device including a user interface generation agent configured for: displaying 
20 a user interface based on said user interface description, for user control of 
said first devices and communication with the external network. 

38. The network system of claim 37, wherein the user interface 
generation agent in the user interface device is further configured for: 

25 using each reference in the corresponding user interface 

description to access the associated information in each first device; 

using each reference associated with services provided by the 
external network to access corresponding service information; 

generating the user interface including: (1) information 
30 corresponding to each first device using the accessed information in 

each first device, and (2) service information; and 

displaying the user interface on said user interface device. 
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39. The network system of claim 38, wherein each reference 
associated with services provided by the external network comprises at least 
one hyper link to service information in the external network, wherein the 

5 service information comprises at least identification information representing 
a service. 

40. The network system of claim 39, wherein the identification 
information comprises a logo information file including a link to a logo graphic 

10 representing the service. 

41. The network system of claim 38 wherein the external network 
includes at least a first portal for providing services, and a reference in the user 
interface description associated with services provided by the external network 

15 comprises at least one hyper-link to said first portal, wherein the first portal 
includes service information comprising at least identification information 
representing said services provided by the first portal. 

42. The network system of claim 41, wherein said identification 
20 information in the first portal further comprises at least a hyper-link to service 

information provided by at least a second portal in the external network based 
on RIC. 

43. The network system of claim 42, wherein: 

25 the external network comprises a plurality of interconnected computer 

systems programmed to provide services; 

the first portal comprises one or more of said computer systems 
providing services of the first portal; and 

the second portal comprises one or more of said computer systems 
30 providing services of the second portal. 

44. The network system of claim 29, wherein: 
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the external network includes at least a first portal and at least a 
destination service provider for providing services; 

the first portal configured such that, in response to a service request 
from at least one first device based on a reference in the user interface 
5 description of that first device in the first network, the service request including 
an RIC of that first device, the first portal determines a destination service 
provider based on the received RIC, and the first portal redirects the request 
to the destination service provider. 

10 45. The network system of claim 44, wherein the destination service 

provider in the external network is internal to the first portal. 

46. The network system of claim 44, wherein the destination service 
provider in the external network is external to the first portal. 

15 

47. The network system of claim 44, wherein a reference associated 
with services provided by the external network comprises at least one hyper- 
link to said first portal, wherein the first portal includes service information 
comprising at least redirection information based on RICs to services provided 

20 by other service providers in the external network. 

48. The network system of claim 44, wherein the first portal further 
includes a list of RICs and corresponding destination service provider portal 
addresses, and the first portal is configured for determining a destination 

25 service provider by looking up in said list a destination service provider portal 
address corresponding to a received RIC, and redirecting the request to said 
destination service provider portal address. 

49. The network system of claim 48, wherein each destination 
30 service provider address comprises a URL. 

50. The network system of claim 44, wherein the first portal is 
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configured for automatically obtaining an RIC code at least one first device 
within the first network. 

51 . The network system of claim 29, wherein at least a first device 

5 further includes a software agent for obtaining an RIC for that first device from 
a user. 

52. The network system of claim 29, wherein for at least one first 
device the corresponding RIC comprises an identifier representing the 

1 0 geographical region of the first device. 

53. A control device for providing a user device communication and 
control in a first network of interconnected first devices, the first network 
connected via an interface device to an external network providing services, 

1 5 the control device comprising: 

a user interface description generation agent configured for: 

(a) obtaining information from one or more of said first devices 

currently connected to the first network, said information including device 

information; and 

20 (b) generating a user interface description including: 

(1) at least one reference associated with the device information of 
each of said one or more first devices, 

(2) at least a redirection identification code (RIC) corresponding to 
that first device, and 

25 (3) at least one reference associated with the services provided by 

the external network. 

54. The control device of claim 53, wherein the first network 
comprises a 1394 network, and the external network comprises a non-1394 

30 network. 

55. The control device of claim 53, wherein the interface device 
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comprises a gateway device. 

56. The control device of claim 53, wherein the external network 
comprises a plurality of interconnected second devices providing one or more 

5 services. 

57. The control device of claim 56, wherein each of said second 
devices comprises at least one computer system programmed to provide 
services. 

10 

58. The control device of claim 56, wherein: 
the external network comprises the Internet, and 

at least one of said second devices providing services comprises one 
or more web servers providing services. 

15 

59. The control device of claim 58, wherein a service provided by at 
least one of the devices connected to the external network comprises a web 
site service. 

20 60. The control device of claim 53, wherein each reference in the 

user interface description associated to services provided by the external 
network comprises at least one hyper-link to service information in the external 
network. 

25 61 . The control device of claim 53 further comprising: 

a user interface device capable of displaying a user interface; and 
a user interface generation agent configured for displaying a user 

interface based on said user interface description, for user control of said first 

devices and communication with the external network. 

30 

62. The control device of claim 61, wherein the user interface 
generation agent is further configured for: 
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using each reference in the corresponding user interface 
description to access the associated information in each first device; 

using each reference associated with services provided by the 
external network to access corresponding service information; 
5 generating the user interface including: (1) information 

corresponding to each first device using the accessed information in 
each first device, and (2) service information; and 

displaying the user interface on said user interface device. 

10 63. The control device of claim 62, wherein each reference 

associated with services provided by the external network comprises at least 
one hyper-iink to service information in the external network, wherein the 
service information comprises at least identification information representing 
a service. 

15 

64. The control device of claim 63, wherein the identification 
information comprises a logo information file including a link to a logo graphic 
representing the service. 

20 65. The control device of claim 62, wherein the external network 

includes at least a first portal for providing services, and a reference in the user 
interface description associated with services provided fey the external network 
comprises at least one hyper-link to said first portal, wherein the first portal 
includes service information comprising at least identification information 

25 representing said services provided by the first portal. 

66. The control device of claim 65, wherein said identification 
information in the first portal further comprises at least a.hyper-link to service 
information provided by at least second portal in the external network. 

30 

67. The control device of claim 66 wherein said identification 
information in the first portal further comprises at least a hyper-link to service 
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information provided by at least a second portal in the external network based 
on RIC. 

68. The control device of claim 66, wherein: 
5 the external network comprises a plurality of interconnected computer 

systems programmed to provide services; 

the first portal comprises one or more of said computer systems 
providing services of the first portal; and 

the second portal comprises one or more of said computer systems 
10 providing services of the second portal. 

6S. The control device of claim 53, wherein the user interface 
description generation agent further associates a hyper-link with the device 
information of one or more of said first devices, and associates at least a 
15 hyper-link with the service information provided by the external network, in the 
user interface description. 

70. The control device of claim 53, wherein: (1) the device 
information in each device in the first network includes a user interface 

20 description for user interaction with that device, and (2) the service information 
in the external network includes at least a user interface description for user 
interaction with a service. 

71 . The control device of claim 53, wherein: 

25 the external network includes at least a first portal and at least a 

destination service provider for providing services; 

the first portal configured such that, in response to a service request 
from at least one first device based on a reference in the user interface 
description of that first device in the first network, the service request including 
30 an RIC of that first device, the first portal determines a destination service 
provider based on the received RIC, and the first portal redirects the request 
to the destination service provider. 
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72. The control device of claim 62, wherein the destination service 
provider in the external network is internal to the first portal. 

5 73. The control device of claim 62, wherein the destination service 

provider in the external network is external to the first portal. 

74. The control device of claim 62, wherein a reference associated 
with services provided by the external network comprises at least one hyper- 

10 link to said first portal, wherein the first portal includes service information 
comprising at least redirection information based on RICs to services provided 
by other service providers in the external network. 

75. The control device of claim 62, wherein the first portal further 
15 includes a list of RICs and corresponding destination service provider portal 

addresses, and the first portal is configured for determining a destination 
service provider by looking up in said list a destination service provider portal 
address corresponding to a received RIC, and redirecting the request to said 
destination service provider portal address. 

20 

76. The control device of claim 66, wherein each destination service 
provider address comprises a URL. 

77. The control device of claim 62, wherein the first portal is 
25 configured for automatically obtaining an RIC for at least one first device within 

the first network. 

78. The control device of claim 53, wherein at least a first device 
further includes a software agent for obtaining an RIC for that first device from 

30 a user. 

79. The control device of claim 53, wherein for at least one first 
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device the corresponding RIC comprises an identifier representing the 
geographical region of the first device. 
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